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This  thesis  presents  a  conceptual  view  of  a  reusable 
"Software  Litrary."  Issues  concerning  the  "software  crisis" 
and  its  subsequent  impact  cn  software  development  are 
reviewed.  The  traditional  library  is  described  for  the 
purrcse  cr  comparison  with  the  Soitware  library.  A  fartic- 
ular  example  of  the  Software  Iibrar^,  tie  Program  litrary, 
is  iescritec  as  a  prototype  of  a  reasia.e  iiorary.  «  r.xtr- 
arcnicdl  structure  fcx  a  program  -irrarj  is  discussed  ji 
atprcach  tc  making  the  library  entities  easily  acces  si.-,  be¬ 
ar.  <1  retrievable.  The  roie  of  af  plication  jener  iters  r re¬ 

program  litrary  is  described.  Ine  srecial  features  cf  Ada 
that  support  programming  libraries  are  described.  Finally, 
non  cede  products  in  the  Soitware  Library  are  d^scucsea. 
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I .  INTjEODOCTICN  AND  BACKGROUND 


The  Department  of  Defense's  (DoD)  Annual  Report  F  Y  '81, 
reported  the  DoC  spent  over  33  billion  on  software  with 
these  expenses  teinc  projected  to  grow  to  $30  billion  per 
year  ly  1S9C  £Hef.  1".  These  estimates  are  alarmingly  hi3h; 
what  is  perhaps  worse  is  the  projection  chat  the  costs  or 
software  maintenance  will  rise  significantly  above  the  cost 
cf  original  development. 

As  this  trend  ox  increasing  software  costs  continues, 
two  questions  come  tc  mind:  why  are  the  costs  factors  so 
dramatic:  and  are  the  reasons  resolvable  with  today's 
modem  technology?  The  general  response  to  the  cause  or  the 
hign  cost  cf  software  usually  centers  on  the  highly  purii- 
cined  "software  crisis."  The  crisis  encompasses  all  soft¬ 
ware  related  problems,  frcm  the  srmpliest  to  the  nest 
complex.  More  specifically,  when  referring  to  software 
systems,  the  reasons  for  the  crisis  focus  on  the  issues  of 
the  systems  being  norresponsive  to  user  needs,  unreliable, 
excessively  expensive,  untimely,  inflexible,  difficult  to 
maintain  and  not  reusable  [Bef.  2].  For  the  most  part, 
these  reasons  establish  the  symptoms  of  the  troblem,  rather 
than  identify  the  prctlem  itself.  But,  since  the  problem  is 
not  well  defined,  the  solution  may  conceivably  come  through 
the  alleviation  cf  the  symptoms. 

Tc  help  solve  portions  of  the  software  crisis,  software 
tools  and  technigues  must  be  developed.  The  development  of 
products  is  but  an  initial  step.  The  emphasis  should  be 
placed  or  the  concepts  associated  with  the  software  product. 
One  cf  the  more  prevalent  concepts  to  be  addressed  is  that 
cf  software  reusability.  Because  of  its  broad  definition 
(as  defined  in  a  latter  section)  ,  reusability  clcsely 


relates  tc  otner  concepts  like  comaonaii ty ,  portability, 
modularity,  ua intainalility  and  evolution.  Ihese  relation¬ 
ships  are  described  acre  precisely  in  iRef.  3]. 

Khat  makes  reusalility  sc  crucial  is  the  presumption 
that  a  well  understood  grasp  of  tnis  concept  coulc  indeed 
resolve  seme  of  the  .acknow  ledged  symptoms  of  the  software 
crisis.  1c  suggest  that  reusability  aioi;e  could  solve  the 
crisis  is  ridiculous.  To  use  the  concept  in  conjunction 
with  a  proven  software  methodology  would  seem  more  real¬ 
istic.  But  there  is  little  evidence  tnat  any  practical 
software  development  methodology  along  tnesa  lines  wil. 
available  ir.  the  neai  future. 

Ihe  Software  Library  has  leer,  proposed  as  a  concept  caj. 
software  product  designed  to  help  solve  many  of  the  software 
related  prollems.  Eefore  the  Software  a.  in  ran y  can  re  intro¬ 
duced  as  a  possible  solution  tc  any  of  the  problems  inciudeu 
in  the  software  crisis,  it  must  provide  to  tus  user  the- 
ability  to  identify  and  resolve  the  many  related  symptoms. 
The  Software  Library  is  net  a  new  or  modern  concept. 
However,  as  proposed  in  this  thesis  it  can  ce  designed  as  a 
hierarchical  library  able  to  respond  to  some  of  the  afore¬ 
mentioned  symptoms.  The  extent  to  which  this  software 
product  can  resolve  the  bottleneck  in  software  development 
is  uncertain,  but  the  potentiai  does  exist,  as  will  be 
discussed. 

A.  SCflSABE  LIBBABI E£ 

1.  History  of  Program  binaries 

The  value  of  Software  Libraries  has  teen  recognized 
since  the  introduction  of  computers  and  associated  programs. 
In  the  early  days  of  computers,  iibraries  were  mainly  used 


as  r ep csitcries  for  commonly  used  software.  It  was  rot 
until  the  latter  196C's  and  early  7Q's,  when  the  economic 
cost  factors  (i.e.,  production  and  maintenance)  of  software 
began  to  rise,  that  the  significance  or  the  Software  Library 
became  highly  evident.  There  were  other  factors  instru¬ 
mental  in  reestablishing  interest  an  libraries:  increas¬ 
ingly  complex  problems,  (e.g.,  mathematical) ,  needxess 

duplicaticn  of  code  and  cede  which  was  usually  less  than 
reliable.  Since  a  large  number  of  the  components  to 
housed  in  the  library  were  mathematicax  in  nature,  ^t  btcda>. 
necessary  tc  produce  a  library  that  was  re_iahit,  3crsra.1. 
(able  tc  service  a  bicad  ~,roup  of  us^rs)  ana  accurate. 


To  fulfill  tie  requirements  sought  ny  the  users  c: 
the  libraries,  the  IHSL  (Internationa^  Mathematical  and 
Statistical  Libraries,  Houston,  Texas)  and  t*.e  A -i 
(Numerical  Algorithms  Group,  Cxford,  Sagianaj  Libraries  were 
introduced.  From  these  licraries  and  otners  of  this  era, 
the  concept  of  the  Pregram  Library  evolved. 

2 .  A  General  Definition  of  a  Program  Library 

The  IMSL  and  NAG  Libraries  can  be  considered  as  good 
Software  Libraries,  highly  effective  in  accompnsnir 3  tneir 
design  goals.  That  is  not  to  say,  that  eitner  would  provide 
the  best  basis  for  defining  the  Program  library  envisioned 
hy  this  author.  To  give  an  appropriate  definition,  regu^re- 
ments  concerning  today's  (1984)  technology  must  he  incorpo¬ 
rated.  One  of  the  basic  demands  of  current  users  of  a 
library  is  for  organized  storage,  search  and  retrieval  or 
entities  (e.g.,  programs  and  their  components)  witiiir  the 
library.  ether  concerns  include  tie  ability  to  manipulate 
(i.e.,  modify,  link,  update  and  list)  entities.  These 
issues  are  important  because  the  users  of  a  library  will  in 
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general  be  people  other  than  the  author  or  the  entities, 
finally/  the  library  should  have  suer*  assets  as:  speed, 
efficiency  and  effectiveness.  Ine  re auiremer.ts  aentiocec 
amove,  lead  to  a  definition  of  a  Program  Library:  "A  stan¬ 
dardized  collection  of  proven  entities  to  re  stored/ 
retrieved  and  manipulated  by  a  user." 

3  .  ft  a  tus  of  ?r  ccra  e  Libraries 

A  review  of  existing  Program  Libraries  shows  that 
there  is  wide  variability  in  quality.  According  tc  £Ref.  4] 
the  EEArE  Program  Library  represents  a.,  ur.  reliant  scarce  or 
software.  Even  thcuch  the  lihrary  provne-s  oar  I  j  r  o  r  u  1  an., 
shareable  routines,  the  number  of  routines  which  rail  to 
work  as  advertized  is  unacceptanlly  a  l  g  a .  On  the  otter 
extreme,  I KSL  provides  a  library  that  is  rijii;  successful: 
a  programmer  who  has  the  resources  of  tae  I1SL  Library  is 
literally  wasting  time  and  money  if  he  cr  she  roses cs  so 
vritirg  software  which  performs  any  of  the  proven  functions 
supplied  ty  I3SL. 

«ith  the  success  of  the  IMSL  and  similar  libraries, 
why  has  there  net  teen  more  widespread  use  of  the  Program 
library?  Why  is  research  on  Program  Libraries  virtually 
nonexistent?  The  economics  involved  could  be  part  of  the 
reasoning  cr  possibly  there  is  a  lac*  of  understanding  of 
wnat  a  truly  guality  library  should  offer  a  user. 


4 .  Evaluation  of  Prour  am  libraries 

The  significance  of  the  Program  Library  has  been 
emphasized  ever  the  past  20  cr  so  years,  but  still  there  has 
not  teen  signs  of  growth  in  the  number  cf  libraries.  These 
Program  Libraries  (cr  similar  software  tools)  that  have 
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proven  tc  te  efficient  and  cost  effective  have  dominated  the 
computer  industry  and  have  establisned  guidelines  for  future 
developmental  software.  fiice  and  Schwetnur  sj3gest  in 
£fie£.  4],  that  there  are  at  least  three  requirements  «..ich 
should  te  present  in  any  quality  library; 

1.  A  large  supply  of  useful,  reliable  parts 

2.  A  catalog  of  parts.  Baking  them  easy  to  locate  an i 
evaluate,  and 

3.  A  mechanism  fcr  connecting  *.arts  together,  sc  as  to 
fern  more  complex  oagects. 

Using  these  require aents  as  an  evaluation  tcoi,  an 
evaluation  scheme,  as  shown  in  larle  I,  can  be  used  cc  rate 
existing  libraries.  The  requirements  as  enumerate!  areve 
are  net  all  inclusive  and  without  economic  justif icaticr.  (in 
time  and  money)  the  library  can  not  be  fully  evaluate! 
against  these  or  any  other  requirements.  With  established 
methods  cf  evaluating  Program  libraries  and  economic  reasons 
justifying  future  developments  in  thus  area;  why  r.as  tuis 
not  teen  practiced  mere  widely?  In  seekinq  the  answer,  this 
thesis  suggests  that  many  cf  the  motivation  factors  (i.e., 
reusability,  portability,  generality,  etc.)  nave  not  beer 
completely  understood.  Once  these  and  ether  issues  are 
incorporated  into  the  evaluation  seneme  ror  quality  Program 
libraries,  the  motivation  necessary  to  design  these  and 
ether  software  products  can  be  better  understood.  Some  of 
these  motivation  issues  will  be  explained  in  this  thesis, 
hopefully,  this  will  benefit  the  future  developmental  soft¬ 
ware  products. 


£.  ECCHCHICS  OF  THE  EOFTWA  BE  IIBBABY 

It  nas  teen  stated  in  £ Bef .  5],  that  by  1S90  there  could 
te  as  many  as  1.2  iillion  programmers  in  demand  with  the 


Evaluation  of  Program  Libraries 


TYPE 

11  3rA.fi  Y 

EEGUIRE- 

«EN1S 

- 

EATINGS 

a£«A3KS 

i  a  si 

1 

“* - 

E 

When  used  with  mathemati¬ 
cal  and  statistical 
applications 

2 

" - 

A 

Available,  but  not  easy 
to  locate  routines 

3 

"  ' " 

Has  no  in  ter  con  nee  tier, 
scheme,  defends  on  out— 
side  rrojram ain j 

NAG 

1 

E 

' 

Primarily  for  matneoati- 
cal  and  statistical 
applications 

2 

E 

Has  its  own  indexing 
scheme,  whicn  is  accessi¬ 
ble,  partially  in  machine 
reaaanle  form'  j 

3 

E 

Has  built-in  linking  j 

mechanism  | 

1 

i 

: 

UNIX 

1 

E  ! 

Has  large  number  of  com¬ 
mands  and  programs  icr 
various  applications 

2 

A 

Available  in  manuals  and 
KKIC  indices 

3 

E 

Oses  pipe  mechanism  as  an 
interconnection  seneme, 
tut  only  for  single 
streams  or  characters 

♦Characteristic  ratings  as  follows: 
E  -  Excellent 
A  -  Average 
£  -  Poor 


actual  supply  of  capable  programmers  failing  to  rise  fast 
enough  tc  close  the  gap  between  supply  and  demand.  fcnile 
this  situation  onlg  represents  a  small  portion  of  the 
cverall  crisis,  there  would  seem  to  be  enough  of  a  problem 
to  warrant  more  concern  tnan  is  presently  exhibited.  What 


appears  even  more  astcnis.ii  ng,  is  tae  fact  tnat,  these  and 
ether  problems  have  not  resulted  in  massive  efforts  to 
develop  software  products  which  could  possiniy  resolve  seme 
cf  the  problems  of  supply  and  demand. 

As  cited  on  numerous  occasions,  the  Sortware  Library  has 
teen  around  for  a  rumter  of  years,  tut  yet  it  nas  not 
significantly  evolved  into  the  type  of  product  capable  of 
resolving  any  of  the  major  effects  of  the  software  crisis. 
This  could  te  due  tc  the  lack  of  Software  binaries  in 
industry.  So,  why  are  they  so  scarce?  It  could  he  tnat  the 
concept  cf  a  Software  Library,  more  specifically  a  lrc3ram 
library,  fails  to  project  substantial  savings  (±.e. ,  in 
time,  ir  money  or  in  productivity)  to  the  user.  It  cc jid 
also  te  that  each  organization  is  waiting  for  the  ether  to 
take  the  first  step.  Of  course,  it  could  re  due  to  soma- 
tning  ether  than  any  issue  discussed  thus  far.  Tc  pursue 
the  guestion  even  further,  one  must  wonder  if  tae  concept  of 
a  reusable  Irogram  library  will  actually  reduce  the  amount 
cf  redundancy  in  program  writing.  Or  will  the  time  spent 
searching  for  existirg  library  components,  outweigh  any 
savings?  These  are  but  a  few  or  the  issues  that  may  navt 
lessened  irterest  in  evolving  the  Software  library. 
Although  the  economic  pitfalls  of  a  software  product,  m 
this  case  the  Software  Library,  may  never  be  fully  realised 
cr  resolved,  it  is  still  the  responsibility  of  the  designer, 
tae  implementor  and  the  user  to  insure  that  tae  many  ques¬ 
tions  surrounding  the  economic  issues  have  seen  addressed. 

Cnee  there  is  a  letter  understanding  of  reusability  and 
the  Software  Library,  there  can  be  a  more  widespread  use  of 
the  ccncepts.  That  is  to  say  that  certain  issues  such  as 
time  spent  reproducing  and  testing  a  program  can  be  better 
utili2€d.  There  are  other  economic  issues  each  affecting 
the  software  crisis  in  some  unig-ue  manner.  The  economic 
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issues  are  important  to  the  future  of  software  development. 
At  understanding  of  the  problem  is  rot  enougt  to  solve  tne 
problem,  tut  with  the  implementation  of  such  concepts  as 
reusability,  the  software  crisis  may  te  reduced  tc  a  mere 
manageable  problem. 

1.  reusability  ard  Portability 

Cf  tne  many  aotiva ti oas,  driving  t.ie  net  d  for  a 
Software  library,  there  are  two  very  closely  related 
notices.  They  ace  portability  aou  reusability.  In  seeding 
a  relationship  which  test  exemplifies  tne  closeness 
tne  two  concepts,  tie  following  representation  seers  appro¬ 
priate:  reusability  should  ce  considerea  a  necessary,  rut 
not  sufficient  condition  for  portability.  Ihis  snows  tne 
relative  importance  cf  reusability,  nowever  each  concept 
will  te  discussed. 

a.  Reusability 

Reusability  has  teen  identiritd  as  a  Xey  tc  the 
effectiveness  of  the  Software  Library  and  as  a  concept  rcr 
helping  to  solve  the  previously  mentioned  software  crisis. 
Unfortunately,  there  is  not  one.  unique  definition  tc  sutrcrt 
the  concept  of  a  Software  library  associa ted  with  reusable 
software  issues.  Therefore  to  establish  a  basis  for  under¬ 
standing,  the  following  definition  will  be  used:  "Software 

resources  of  a  capital  nature  which  are  used  in  tne  develop¬ 
ment  cr  maintenance  of  software  products  with  end  uses 
different  from  that  cf  the  component  resources."  further 
ciarif icaticn  also-  provided  by  the  reference  encompasses  any 
information  generated  at  any  time  threugnout  the  software 
.life-cycle.  Also,  a  component  resource  is  described  as  a 
modular  product  of  tie  software  life-cycle,  possessing  the 
characteristics  of  bein3  highly  cohesive  [Ref.  6j. 


In  [Bef.  fc],  the  author  presents  a  list  ci  major 
factors  which  dictate  the  usefulness  of  reusable  software. 
Ine  greatest  concern  is  that  acceptance  of  a  product  would 
not  be  forthcoming  if  the  product  is  not  understood.  Inus, 
if  a  product  does  net  appear  easy  to  use  and  economically 
feasible,  then  there  would  be  little  desire  to  understand 
it.  A  product  can  net  prove  itself,  if  it  is  not  used. 

Since  the  concept  of  “reusing"  software  has  tee,, 
around  for  so  long,  technological  improvements  in  this  neld 
should  be  researched.  The  conceptual  Program  library  repre¬ 
sents  a  source  to  be  used  as  a  guide  for  future  development 
cf  reusable  software. 

t.  Portability 

The  concept  of  portability  has  existed  since  tne 
discovery  that  large  savings  can  be  realized  :: cm  tae 
distribution  of  good  software.  But,  as  touched  or  by  Jean 
Eice  £Bef.  7],  the  dissemination  of  guality  software  is 
opposed  by  formidable  barriers,  such  as  the  dependency  of 
software  cn  machines  and  the  idiosyncrasies  of  compilers  and 
operating  systems.  Iven  though  Kice  was  referring  specifi¬ 
cally  tc  numerical  computation  software,  his  comments 
warrant  consideration  by  any  organization  contemplating  the 
development  and  transportability  of  a  new  software  rrcduct. 

Portability  deals  with  tne  designing  cf  a 
product  that  will  mirioize  the  amount  of  change  required  to 
move  the  product  from  one  environment  to  another. 
Portability  alsc  takes  into  consideration  most  issues  of 
compatibility  which  affect  the  transportability  of  a  soft¬ 
ware  product. 


The  Program  Library, 


wnile  not  specifically 
designed  as  a  portable  software  product,  should  h ave  capa- 
bilities  consistent  with  portability  issues.  The  reasoning 
is  that  portability  issues  rerresent  a  fora  of  enticement  to 
the  user.  After  being  influenced  to  use  a  product  its 
benefits  can  be  better  understood.  Taus,  the  added  facility 
cf  portability  can  be  treated  as  a  motivational  concept  for 
hexping  the  conceptual  Program  Library  resolve  some  cf  the 
i-robleis  inherent  tc  the  software  crisis. 

The  environment  cf  tne  Program  library  anc  the 
user  snculc  determire  which  concepts  require  tr.e  rest 
enpnasis.  In  an  attempt  tc  reduce  tne  errects  of  the  sort- 
ware  crisis  noth  concepts  (portability  and  reusability) 
should  be  considered  essential  to  tne  user  cr  tne  Program 
library . 


2.  Standardization  of  the  Software  Library 

The  efficient  and  effective  understanding  cf  soft¬ 
ware  products  written  by  others  is  one  cf  the  critical  prob¬ 
lems  in  software  development.  Juch  of  tne  labor  expense  in 
software  development  is  involved  in  the  understanding  cf  the 
various  software  products.  One  approacn  to  this  prebiem  has 
been  tc  apply  standards  to  software  products. 
Standardization  allows  people  who  are  familiar  with  parts  cf 
a  software  product  tc  more  easily  become  familiar  witr  ctner 
parts.  Some  of  the  areas  of  concern  to  standardization 
include : 

Fermat 

Documentation 
Sped  fication 
Test  Flans 
Error  Handling 
Modularity 
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lhe  standardization  or  products  makes  it  faster  (and 
thus  acre  efficient)  to  understand  a  sortware  product  ere 
has  net  seen  before.  Standardization  jls  critical  tc  the 
Software  Library: 

1)  if  users  other  than  the  criamator  are  to  easily  ac¬ 
cess  and  retrieve  items  in  the  Library, 

2)  if  items  in  the  library  are  to  me  incorporated  without 
change  intc  otter  larger  standardized  software  tic- 
ucts, 

3)  and  if  the  library  is  to  be  nuixt  and  maintained 
efficiently. 

Since  standardization  represents  suen  a  cnt.ca* 
aspect  in  software  development  mere  snoulu  ne  management 
mechanisms  established  to  enforce  standards.  These  mecha¬ 
nisms  should  not  discourage  the  use  of  the  library,  ineteaa 
tuey  should  suggest  an  ease  cf  use  preferable  to  writing 
one’s  cwn  cede. 

3.  Reliability  ir  a  Software  Library 

"The  ever-increasing  expectations  and  needs  cf  large 
organizations  and  the  advent  cf  large,  chea*.  mtiories  has 
led  tc  the  creation  cf  ever-  larger  information  systems. 
One  cf  the  results  has  teen  the  discovery  that  while  a  small 
system  cculd  often  be  thoroughly  tested,  for  all  practical 
purposes  large  systems  of  interacting  nardware,  software  end 
people  cculd  be  rendered  useless  because  ox  unreliabili ty . 
Since  the  physical  ar.d  econcaic  consequences  of  mfaraatxon 
systems  failure  may  be  very  great,  interest  xn  reliariity 
has  grewr  also,"  £Hef.  8  J. 


One  definition  of  reliability  found  in  [Bef.  8] 
suggests  the  following:  "a  piece  of  software  that  is  correct 
with  respect  to  stated  requirements  and  that,  further,  is 


anle  to  withstacd  unanticipated  atadiiac  as  «aii." 
for  reliability  late  tacx  a  number  of  years  tc  wren  usa,e  of 
the  Software  Library  began.  Che  primary  concerus  teen  were, 
that  the  library's  reliability  be  exhin itsd,  in  its  accuracy 
and  in  its  mathematical  stability.  Ire  need  for  reliability 
in  a  Software  Library  has  not  cnan3ed  over  time,  but  there 
is  little  evidence  that  software  development  has  met  these 
demands  with  more  reliable  Software  Libraries.  Ire  finan¬ 
cial  investments  and  researcr.  in  software  development  s  =  em3 
to  grew  slowly,  even  though  the  reasons  justifying  suer  a:, 
investment  seem  overwhelming. 

with  a  renewed  relief  that  tnere  is  a  need  for  see., 
reliable  software  prcoucts,  alj.  taat  will  l~  required  is  a 
product  that  will  suggest  eccncaic  reasons  rcr  industry  and 
LoO  tc  invest  in  further  research.  Ihe  conceptual  Softer- 
library  proposed  by  this  thesis  will  nopefuily  irrlter.ee 
such  interest. 

4 .  Generality 

for  a  Software  Library  to  support  the  concept  of 
reusability,  its  design  and  the  design  cf  the  components 
within  its  structure,  must  offer  a  certain  amount  of  gener¬ 
ality.  Parnas  £Ref.  9]  states  that  software  can  be  consid¬ 
ered  "general"  if  it  can  be  used  without  change  in  a  variety 
cf  situations,  Thcs,  the  concept  of  reusanility  wnich 
emphasizes  modification  (i.e.,  change)  represents  a  conflict 
with  the  concept  of  generality.  Parnas  also  states  that 
software  can  be  considered  "flexible"  if  it  is  easily 
changed  tc  be  used  in  a  variety  of  situations.  Ibis  rcticr. 
cf  flexibility  is  more  consistent  with  reusability. 

Based  on  Parnas'  definitions  the  best  way  of 

achieving  generality  in  a  proposed  reusable  product  is  to 


have  scae  form  of  balance  between  me  concepts  or  yeseiaiit; 
and  flexibility.  The  actual  balance  is  between  the  rur-tiie 
costs  to  be  paid  for  generality  and  the  design-cost  innerent 
to  flexibility.  The  designer  of  a  software  product  nay  ret 
readily  rind  this  balance.  But  ix  he  or  she  maxes  a  consci¬ 
entious  effort  at  deciding  this  issue,  a  resulting  reusable 
product  will  be  more  achieveable. 

C.  GEHEBAI  DEFIHITICS  OF  A  SCIT1ARE  LIBBABY 

Fcr  the  most  part  the  Software  Linrary  and  the  issues 
surrounding  it  have  stressed  code  oriented  goals.  *tile  t.-.e 
Software  library  is  designed  tc  support  various  terms  ci 
code,  tc  center  on  this  aspect  is  not  consistent  with  the 
expectations  of  the  cverall  software  product.  The  Software 
library  will  serve  the  user  and  his  organization  best  if  it 
is  defined  in  a  breader  context.  The  iirst  step  is  to 
insure  that  the  semartics  of  the  term  "entity"  induce  docu¬ 
mentation,  specifications,  designs,  requirements  and  test 
plans,  as  well  as  code. 

The  acre  general  definition  of  a  Software  Library  is  "a 
standardized  collection  cz  reusable  software  products 
designed  tc  enhance  economic  savings  through  tne  manipula¬ 
tion  and  modification  of  its  reusable  entities." 

D.  S1B0CT0BE  OF  THE  3HESIS 

Chapter  II  discusses  the  automated  traditional  library. 
Since  the  user's  reguirements  for  a  traditional  library  are 
similar  tc  those  for  a  Software  Library,  this  chapter  gives 
some  insight  into  the  functions  of  the  conceptual  Program 
library.  Chapter  III  presents  criteria  ‘to  assist  in 


ieco^ciziEg  quality  Software  ..itraries.  It  compares  vancus 
existing  Software  Libraries  and  suggests  how  they  light  be 
used  to  establish  guidelines  for  future  develcpmentaA 
libraries,  specifically  the  Pregram  Library. 

Chapter  IV  introduces  a  hierarchical  representation  ox  a 
Program  Library  that  is  uriike  most  contemporary  Program 
libraries.  The  discussion  stresses  how  this  structure  car. 
improve  the  library's  operation  with  regard  to  software 
reusability.  Chapter  V  describes  a  application  generator. 
Its  cesicn  consists  cf  program  generators  structure!  in  a 
hierarchical  fashior  at  a  level  axgaer  tr.an  the  nxgnest 
level  in  the  Program  library.  This  chapter  will  explain  hew 
this , software  product  will  assist  the  user. 

Chapter  VI  outlines  an  on-line  method  of  searching  ana 
retrieving  entities  in  the  Program  Library.  The  Library 
Eefeience  Guide  discussed  in  this  cnapter  reasserts  a 
manageable  interface  between  the  library  and  tne  user.  In 
Chapter  VII,  the  programming  language  Ada  is  provide!  as  an 
existing  language  capable  of  meeting  some  on  the  xeguire- 
aents  of  the  conceptual  Pregram  Library.  Sany  of  the 
concepts  in  Ada  are  still  herng  researched,  but  in  general 
Ada  is  a  language  with  potential  usefulness  for  a  Program 
library. 

Chapter  VIII  discusses  how  the  concept  or  a  Software 
library  can  be  extended  to  non  code  software  products. 
These  products  include:  documentation,  r eguiremects ,  speci¬ 
fications,  designs  and  test  plans.  Chapter  IX  is  the 
concluding  chapter.  It  presents  a  general  overview  cf  the 
thesis. 


II.  THE  AUTOMATION  01  TEE  TRADITION A1  IIBSAEY 


lie  traditional  library  represents  a  wealth  of  knew leage 
in  the  fcim  of  hooks,  journals,  serials,  reports  ard  so 
forth.  Iherefore  the  concept  behind  the  automation  or  such 
massive  resources  presents  the  stiffest  of  challenges  to 
modern  technology.  The  complexity  of  toe  challenge  is 
increased  because  of  the  usual  opposition  to  the  changing  or 
a  so  called  "working  system."  To  address  this  resistance  to 
cnange,  an  aspect  of  automation  beneficial  to  librarians  a:, 
library  users  wili  be  stressed. 

The  aspect  of  interest  is  the  application  of  computers 
to  information  processing.  A  specific  concern,  familiar  to 
the  Software  Library,  is  hew  tc  process  the  data  neeoei  nor 
control  ever  and  for  access  to  information.  Another  concern 
is  in  the  approach  used  oy  an  individual  to  interact  witn 
the  ccmputer  system.  Existirg  and  future  technology  acccm- 
panied  ty  convertioial  practices  witain  the  library  should 
produce  products  able  to  respond  to  these  and  ether 
concerns.  These  issues  are  resolvable  given  an  adeguate 
understanding  of  the  distinction  between  requirements  ana 
the  actual  design.  The  gist  of  the  distinction  is  tnat 
requirements  are  independent  of  any  specific  desigr  for 
implementation.  To  convince  the  skeptics  of  the  future  of 
automation  withir  the  library,  the  basic  criteria  associated 
with  existirg  library  services  should  be  discussed.  The 
traditional  library,  as  it  stands,  may  not  provide  all  the 
services  expected  of  an  automated  system,  therefore  tc  view 
tne  library  in  the  correct  perspective,  issues  other  than 
speed  and  efficiency  should  be  introduced.  Prior  to 
discussing  futuristic  criteria  for  an  automated  system,  the 


expected  .functions  ox  the  library,  as  viewed  by  tte  user, 
oust  be  described. 

1 .  acquirements  cf  tne  Automated  tradition!  library 

lo  the  average  user,  tne  Automated  traditionax 
library  is  somewnat  cf  a  remote  concept.  Thus,  tc  lessen 
this  sense  or  remoteness,  the  knowledge  of  beer.  t-e 
librarian  (since  he  or  sne  is  in  constant  contact  with  tne 
user)  and  tne  engineer  {  whc  has  designed  many  automate: 
systems)  is  required.  Tne  purpose  is  tc  comrint  this  >rcwi- 
eagc  into  a  concerted  effort  for  t  be  desx3fj  and  1  Bpiemer.  ra¬ 
tion  cf  the  most  effective  user-friendly  system.  rased  cr 
research  cf  user  needs  and  cn  the  interests  of  the  user, 
tnere  snculd  be  some  term  of  ccamuuica tion  network  tying  tne 
user  tc  an  automated  catalog  and  other  bmiio-,  rapnic  tools 
related  to  a  large  library  cr  a  system  of  libraries.  Or.ct  a 
text  is  identified  there  should  be  guicx  delivery  Cu£a- 
bility.  There  snould  definitely  re  some  form  or  user  inter- 
acticr  with  the  system,  thus  providing  responsive  guery 
services  to  the  user  while  he  or  she  attempts  to  make  series 
cf  rapid  and  repeated  searches.  fase  of  access  tc  tne 
information  must  be  provided  by  terminals  (local  and 
remote).  finally  the  system  should  display  detailed  infer- 
maticr  cf  a  text  and  prior  to  responding  tc  a  reguesc  for  a 
hard  copy  the  system  should  provide  to  the  user  the  ability 
to  view  pages  of  selected  works.  An  important  point  to  be 
stressed  is  that  the  functions  descrined  abeve  are  net  to  be 
thought  cf  as  independent  functions,  instead  certain,  if  not 
ail,  are  interrelated. 

Kith  the  recuireaents  of  tne  automated  system  as 
suggested  above,  the  selection  of  rer xormance  criteria  nom 
the  users  point  of  view  can  new  be  presented  in  the  next 


sections.  It  must  i€  rteffl^hasized  tnat  tncse  criteria  are 
only  tc  ie  looked  a  ecu  as  guidance  towards  fulfilling  the 
suggested  requirement,  and  as  requirements  change  sc  dc  the 
performance  criteria  (tnis  suggests  tne  need  ior  flexibility 
in  design) . 

2.  Associated  P exforma  nee  Criteria 

The  performance  criteria  whicn  are  suggested  as 
tein3  necessary  to  the  user,  include  tne  foliewing: 

1)  user  interactici  with  computer 

2)  aids  to  browsing  textual  information 

3)  a  user-indexed  library 

4)  access  to  different  levels  of  information 

5)  ccirmurication  between  remote  sources 

6)  extensive  software  tools 

7)  rapid  response  time 

Although  each  of  the  aforementioned  criteria  is  a 
majen  concern  tc  the  user,  it  us  not  within  the  sccgc  of 
this  thesis  to  describe  in  detail  each  criteria.  £c  as  to 
remain  consistent  with  the  overall  purpose  (i.e.,  the 
discussion  of  the  conceptual  Program  Library),  or.ly  the 
peri crmance  criteria  associated  with  .  the  user  interaction 
with  the  computer  will  be  discussed  in  any  detaxi. 

Ihe  interaction  reguired  between  the  user  arc  the 
Automated  traditional  library,  snouiu  not  be  thought  cf  as 
removed  from  the  control  of  the  librarian.  Ihat  is  tc  say, 
the  librarian  is  an  integral  part  of  the  automated  system, 
lo  he  mere  specific,  the  librarian  exists  as  a  reference 
source  capable  cf  providing  expert  reference  assistance  in 
specific  disciplines  where  detailed  knowledge  is  reguired. 
He  or  she  would  also  be  expected  to  have  access  tc  ether 


librarians,  thus  increasing  the  degree  or  detail  available 
cn  a  given  subject.  The  triangle  created  between  the  user, 
the  librarian  and  the  automated  system  add  emphasis  tc  the 
need  fcr  an  effective  communication  retworx,  and  therefore, 
the  need  fcr  a  user/litrari an  interaction  with  the  computer 
becomes  mere  essential. 

Iresent  day  technology  su33ests  that  the  terminal 
xtytoard  is  the  most  adequate  form  of  interaction  tetwee.. 
the  automated  library  system  and  the  user.  in  keep-in.,  .  at:, 
the  ncticn  cf  simplicity,  only  a  limited  number  of  terairax 
related  functions  will  he  identified.  Den  5.  Swanson 
£Bef.  10*,  a  librarian  with  asrira tions  ror  designing  a 
mechanized  library,  presented  his  concept  cf  interaction 
under  the  definition  cf  "programmed  interrogation."  In  ms 
presentation  of  the  term  programmed  interrogation,  i.e 
suggests  six  major  "process  ccntroi"  Keys  used  tc  provide 
the  user  with  an  initial  set  cf  cnoices  at  a  console.  Tntse 
six  keys  are  consistent  with  the  terminax  related  functions 
suggested  by  this  thesis.  Therefore,  the  functions 
presented  will  be  briefly  described  with  Swanson's  concepts 
in  mind. 

The  first  furctioa  necessary  for  a  good  working 
environment  is  labeled  "specific  work."  Its  purpose  is  to 
identify  the  reguest  fcr  a  specific  book,  journal  on  report 
by  means  cf  author,  title,  publisher,  or  other  descriptive 
(non-subject)  information. 

The  next  function  labeled  "subject  selection" 
permits  retrieval  of  material  based  on  subject  classifica¬ 
tion,  index  or  keywords.  It  also  allows  retrieval  of 
specific  information  and  finally  it  permits  browsing  cf  the 
above  information. 


Another  function  labeled  "previous  selecticr."  allows 
the  user  the  ability  to  select  any  material  ne  or  any  ether 
specified  person  has  used  before. 

The  "similarity  selection"  is  another  function  usei 
to  initiate  a  chain  cf  bibliographic  citations  that  satisfy 
specified  work. 

The  function  laoeled  "coabinat ion"  allows  the 
linking  cf  any  two  functions. 

The  next  function  is  lareied  "sequence  display"  rcr 
its  ability  to  step  the  display  from  one  display  tc  anctner. 

A  final  function  labeled  "microfilm  view"  is  used  to 
call  fer  a  microfilm  display  of  selected  portions  cf  an; 
work  identified  cn  tie  CRT  display. 

The  function  lanels,  as  described  above,  are  rot 
designed  to  suggest  an  ail  inclusive  view  of  the  terminal 
keyboard  necessary  tc  provide  user  interaction  with  the 
system.  But,  what  it  does  suggest  is  a  selection  cf  func¬ 
tions  considered  basic  to  the  operation  of  the  lirrary. 
Cnee  the  inguiry-response  interaction  has  been  effected 
between  the  user  and  tne  automated  system,  a  basic  format 
(possibly  based  on  tie  bibl iography)  can  be  established  as  a 
guide  cr  training  device  in  the  use  of  tne  system.  with 
this  guide,  the  user  has  an  example  of  the  response  received 
from  a  properly  formulated  inguiry.  Issues  in  regards  to 
waether  an  inguiry  is  too  broad,  too  narrow  or  too  ambiguous 
should  become  mere  obvious  as  tne  interaction  become  mere 
freguent.  The  underlying  result  is  tnat,  the  user  improves 
cn  his  or  her  level  cf  understanding.  Tne  Automated  tradi¬ 
tional  library  once  understood,  could  oe  used  effectively  as 
a  tool  fer  increasing  the  researen  potential  of  the  user  and 
cf  the  librarian. 


'  .V  *-  /•  *• 
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III.  CHARACTER IS 1ICS  RELATIVE  TO  A  PROGRAM  LIERAB Y 

A.  E2ISTIMG  CHARACTERISTICS 

Two  organizations  have  produced  large/  portable,  gcou 
guaiity  and  inexpensive  libraries.  They  are  IMS;. 
(International  Matheaatical  ana  Statisticax  libraries, 
Houston,  Texas)  and  NAG  (Numerical  Algorithms  Group,  Oxford, 
England).  Both  litraries  are  evaluatea  with  reguarc  to 
their  existing  characteristics  a~d  t..e  characteristic.: 
primarily  suited  to  the  reusability  concert.  Although  tne 
software  developed  by  these  two  ^roags  consists  large Ly  or 
numerical  subroutine,  this  does  not  exclude  the  feasibility 
cf  using  therr  concepts  cc  ether  ty^es  of  software  prc-sucts 
(i.e.,  nen-r umerical) . 

Ir  discussing  the  libraries  developed  by  IMS!  3sc  HA',, 
tee  authcr  is  net  implying  teat  the  characteristics  repre¬ 
sented  by  eacn  is  better  or  worse  than  any  other.  But  tue 
objectives  cx  the  twe  libraries  are  close  to  those  desired 
in  the  conceptual  Pregram  Library.  The  characteristics  cr 
lack  of  will  be  discussed  for  botn  the  IMSL  and  RAG 
libraries  and  hopefully,  the  concept  or  tne  Program  library 
will  become  evident  tc  the  user. 

E.  TEE  1HS1  LIBRARY 

The  IMS!  library  consists  of  over  400  high  quality  math¬ 
ematical  and  statistical  subroutines.  These  subroutines 
represent  programs  derived  from  a  variety  of  sources 
(includirg  ones  written  by  IMSI)  .  Regardless  of  the  source 
,  all  programs  are  rewritten  with  a  uniform  (i.e.,  standard) 


style.  According  to  rice  [Bef.  7  ],  quality  control  is  exer¬ 
cised  by: 

(a)  choosing  good  sources  (the  advisors,  a  board  of 
11-15  experts,  assist  in  this  regard) 

(b)  usiEg  knowledgeable  programmers  with  good  supervi¬ 
sion  (some  of  the  senior  IMSL  people  work  regularij 
cn  the  library  programs) 

(c)  testing  (reasonably  exnaustive  for  ..ew  programs, 
check  roint  testing  for  maintenance  or  new  machine 
versions) 

(J)  continual  upgrading 

As  picrcsed  in  [Bef.  11],  the  IliSL  library  has  moved  to 
a  Fortran  converter  system  where  a  master  file  contains  ai^ 
the  information  needed  for  eacn  machine  version  of  a 
program.  Much  of  the  standard  inxornation  is  not  exp ..icitij 
in  tie  file.  A  converter  program  then  automatically 
produces  the  program  for  a  particular  target  macnine.  The 
master  file  is  itself  a  Fortran  rrogram  that  runs  on  one  on 
the  machines.  Thus  portability  is  an  attribute  of  the  IhSL 
library. 

The  characteristics  of  the  IilSL  library  subroutines  and 
documentation  are  of  major  concern  to  a  user.  Aside  from 
the  standardization  cf  the  documentation,  there  should  be  a 
good  understanding  of  the  general  attributes  residing  in  the 
library.  The  attriictes  [Ref.  12]  are  as  follows; 


(a)  Testing  of  the  library  subroutines  were  performed  at 
several  levels  in  various  computer/compiler  environ¬ 
ments  . 

(b)  For  each  routine  which  has  some  enror  detecting 
capabilities,  the  user  is  protected  ny  default.  That 
is  if  the  user  chooses  tc  ignore  error  possibilities 
a  warning,  in  the  form  of  a  printed  message,  is 
issued. 

(c)  mach  routine  conforms  tc  established  conventions  ir. 
ceding  and  documentation. 

(d)  £ach  routine  was  designed  and  documented  to  re  used 
hy  technical  personnel  in  fields  of  science,  engi¬ 
neering,  medicine,  agriculture,  .  .  .  ,  and  in  re¬ 
search  activities. 

(e)  Accuracy  of  results,  clarity  of  documentation,  and 
efficiency  of  ceding  were  given  first  priority  in 
development. 

(f)  Periodicals  and  books  are  referenced  for  users 
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interested  in  details  oi  algorithm  development. 

{•a)  Crter,  tests  rex  applicability  or  tne  algoritnm  art 
applied;  the  user  is  warned  ir  tne  algorithm  tails. 
Pitfalls  tc  he  avoided  ir  usage  are  noted. 

(h)  All  information  pertaining  to  usage  of  one  routine 
is  in  one  place.  Documentation  is  a  conii3 uraticn  or 
typed  material  and  computer  readable  documentation 
jin  the  form  of  comment  lines). . 

(i)  Computer  readable  documentation  permits  on-line  ac¬ 
cess  to  basic  dccumen tation.  Computer  readable  mate¬ 
rial  is  distributed  with  source  code. 

(j)  All  routines  have  documented  examples  cf  input  anc 
results. 

(x)  Designers  and  programmers  (or  IMSl  personnel  respon¬ 
sible  for  a  ccae)  are  availacie  to  answer  user 
c  ues  tions. 


Ibe  general  attributes  as  mentioned  are  not  all  ir.c.i.u- 
sive,  rut  are  enough  tc  provide  some  understanding  ::  tn. 
capacity  of  the  library.  To  reinforce  tne  integrity  cr  tre 
linrary,  IMSL,  as  tie  sole  source  of  an^  technical  informa¬ 
tion  regarding  these  routines,  assumes  total  responsioui it^ 
for  the  operation  cf  any  routine.  lo  facilitate  the 
retrieval  cf  tne  various  routines  and  their  associated  docu¬ 
mentation,  IMSL  has  estanlisrea  a  directory  of  rcucir.es  in 
which  each  routine  has  been  placed  in  an  alphabetized 
category.  IMSl  aisc  provide  a  key -word-in-context  (KtfiCj 
listing  which  offers  the  user  a  guick  reference  to  a  routine 
giver  the  user  has  knowledge  of  the  title.  This  is  cot 
always  beneficial  since  there  are  many  cases  where  the  title 
does  net  accurately  reflect  tne  contents  or  tne  routine, 
however,  the  concept  of  a  key  word  retrieval  mechanism  most 
rot  be  overlooked. 


Although  the  IMSl  library  has  tne  many  characteristics 
mentioned  above,  tbe  retrieval  and  manipulation  of  the 
routines  is  generally  hidden  from  the  user.  Should  tne  user 
desire  access  to  the  IMSL  Library,  the  capability  does  exist 
and  the  routines  can  be  incorporated  into  the  user's 
program.  Ihere  are  problems  encountered  when  attemptirg  to 
interleave  a  user's  program  with  -the  IMSL  Library;  usually 


these  problems  are  sere  evident  ±ij  tjie  production  environ¬ 
ment  than  in  an  institutional  or yduizatiou .  The  reason  is 
the  increased  productivity  exrected  by  most  production  orga¬ 
nizations.  The  Ih£L  Library  can  be  used  as  a  guide  to 
conceptualize  a  functional  Program  Library  witn  some  exten¬ 
sions  tc  its  existinc  characteristics. 


C.  1  EE  SAG  LIBBiRY 

lie  NAG  Library  represents  a  hign  quality  numeric!- 
algorithm  library  for  general  use  by  universities.  It  also, 
by  desigr,  represents  a  portable  system.  The  WAG  Lirrar^ 
£Ref.  13*  operates  as  follows: 
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The  SAG  uses  a  master  library  file  system  (similar  to 
the  1KSL  master  file)  which  contains  all  versions  of  each 
program.  It  also  keeps  a  complete  history  of  the  versions 
cf  each  program.  Cue  to  the  high  level  language  (i.e., 
subsets  cf  Fortran,  Algol  60  and  Algol  68)  and  machine 
parameterization,  new  machine  implementations  are  essen¬ 
tially  automatic  (i.e.,  transparent  to  the  user).  Jben  an 
implementation  is  accepted,  the  programs  are  returned  tc  the 
NAG  Central  Office  fox 'inclusion  in  the  master  library. 


There  a^e  stringent  test  pro3rams  for  each  library  routine 
to  assure  equivalent  [erf or mai.ce  of  tne  NAG  Library  versions 
[Eef.  14*.  According  to  £Bef.  15],  the  xinrary  nistcry 
information  and  test  programs  in  tne  master  file  have  been 
round  useful  in  developing  a  cere  ^ortanle  library. 

lie  NAG  Library,  in  a  similar  manner  to  chat  of  the  IXSL 
library,  provides  a  workir3  understanding  of  a  subrcutir = 
library.  Nith  the  concept  of  the  NAG  Lmrary  rein3  usti  as 
a  guide,  the  task  of  establishing  a  Program  Litraij  should 
seen  obtainable. 


L.  C  VEE  VIE  Si  OF  CHAfi  ACIEBIS TICS 

Ktile  the  IKSL  and  NAG  libraries  appear  to  set  tr. e 
guidelines  nor  an  effective  ?rc3raa  Linrarg,  neitner  has  tue 
characteristics  expected  of  a  functionally  reusable  Program 
library  as  proposed  by  this  thesis.  Specifically ,  ret., 
libraries  have  beneficial  characteristics,  but  each  neglects 
the  issues  of  reusability  (e.g.,  cataloging,  key-.cri 
indexirg  and  retrieval,  etc.). 

The  characteristics  of  the  IMSL  and  NAG  Libraries  which 
suppcrt  the  concept  cf  the  Erogram  Library  ‘Will  be  discussed 
and  presented  as  feasible  qualities  to  be  associated  witn  a 
good  library.  To  broaden  the  perspective  of  a  library,  the 
characteristics  and  attributes  of  tne  IrtSL  and  tne  NAG 
libraries  should  be  slightly  modified  and  in  some  cases 
changed  tc  fit  new  gcals. 

A  closer  look  at  the  two  libraries  reveal  the  following 
goals  fcr  a  possible  Program  Library: 

(1)  Tie  design  and  impie mentation  of  the  Program  Library 
should  be  under  the  auspices  of  a  group  of'  experts 
ficn  a  wide  rarge  of  sources  (i.e.,  designers,  pro¬ 
grammers,  etc.}. 


(2)  Ite  environment  of  the  Program  Library  must  re 
established  ar.d  ail  testing  must  be  accompl  isba.i 
within  it. 

(2)  Each  entity  within  the  library  should  he  considered 
for  error  detection  requirements.  Appropriate  error 
handling  capabilities  must  he  outlined. 

(4)  Standardization  or  coding  and  documentation  is  manda¬ 
tory,  for  ail  entities  within  the  library  or  evolved 
from  the  library. 

(5)  lie  clientele  cr  users  cf  the  Program  Library  shou_f. 
be  identified  and  the  library  must  surport  them. 

(6)  lie  developmental  priorities  should  be  set,  so  t..at 
any  latter  tradeoffs  will  be  on  miner  let-urla  as 
opposed  to  major  issues. 

C?)  lie  development  of  the  entities  witnia  tne  library  is 
important  and  although  the  actuaj.  specifics  car  not 
he  placed  in  tie  library,  references  providing  know¬ 
ledge  of  the  details  should  be  made  accessible  tc  the 
user. 

(6)  The  library  should  represent  a  user-friendly  product, 
lhus  when  manipulating  entities  in  the  library  there 
should  be  appropriate  tests  for  applicability  tc  the 
user’s  requirements,  thereby  making  it  possible  to 
quickly  identify  and  avoid  some  or  the  problems  of 
parameterization. 

(5)  lie  library  is  to  be  its  own  best  source  of  informat¬ 
ion.  Any  inquiries  as  to  the  use  or  the  library  will 
be  answered  ty  its  own  documentation,  alleviating 
the  need  for  exterior  (i.e.,Looxs)  information.  Ibis 
implies  ot-lice  access  to  both  the  documentation  and 
tie  ether  entities  as  they  are  used  in  tne  library. 

(10)fcr  the  new  user  of  the  library,  t.*ere  should  be 
example  inputs,  results  and  formatting  restrictions 
and  guidelines. 


t.lo 


(11)  lie  organization  responsible  for  the  concept  cz 

Program  Library  and  its  design  and  implementation 
should  also  be  responsible  to  tne  users  for  continued 
updating  and  maintenance. 

The  aforementioned  characteristics  will  provide  a  good 
guaiity  library  but  what  is  lacking  is  the  charac teristics 
tnat  will  make  the  library  reusable  to  tne  user  arc  his  cr 
her  organization.  Suggested  additional  characteristics 
snould  include  but  net  be  limited  to: 

(1)  Ike  ability  to  select  tbe  most  optimal  entities,  ror 
the  accomplishment  of  the  user's  task. 

(2)  Library  browsing  capability  prior  co  the  selection 
of  a  comrcnent  withir. 

(2)  Ihe  ability  to  locate  a  component  or  a  similar  com¬ 
ponent  with  the  use  cr  keywords,  indexing  and  cata¬ 
loging. 

(4)  Manipulation  ard  retrieval  capabilities  on  entities 
crce  located. 

(5)  The  ability  tc  modify  and  combine  authorized  modules 
sc  as  to  possibly  create  larger  modules  in  a  hier¬ 
archical  manner.  This  should  be  accomplished  wniie 
keeping  the  parameter  passing  process  transparent  to 
the  user. 

£.  SGMH1BI 

As  a  final  comment  on  the  IM5L  and  NAG  Libraries, 
certain  observations  seem  evident.  One  is  that,  as  ni^r  a 
guality  as  the  two  libraries  appear  to  be,  tnere  seems  tc  be 
little  tc  indicate  that  the  issue  or  reusability  is  or  any 
concern.  This  thesis  does  not  deny  that  a  good  library 
could  very  easily  be  created  from  the  image  of  either  the 
I  MSI  cr  the  NAG  library,  however  it  could  re  said,  that  the 
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IV.  I HE  PiCGEAM  LI3BAB Y 


The  Program  Litrary  represents  a  conceptual  design 
respcrsive  to  the  widest  range  of  users  (from  the  novice  to 
the  expert)  .  The  litrary  is  to  he  estaoiisned  arcane  2cais 
consistent  kith  user’s  needs.  To  understand  tne  conceptual 
desigr  and  implementation,  the  goals  or  tne  Program  liirary 
will  he  identified  aid  explained. 

A.  G  C  AIE  Cf  A  PHOGBAt  1IBEABY 

Initially,  the  Program  litrary  should  he  designed  so  as 
to  he  cf  benefit  to  a  wide  range  of  users.  Incluied  m  t ;,io 
design  should  he  considerations  for  reliability,  modin- 
atiiity,  under stardaiility,  testability  and  efficiency. 

Arcther  goal  is  to  nave  a  library  that  nas  powerru* 
capabilities  and  has  the  flexibility  to  be  easily  modiriel 
to  fit  specific  user  needs.  tfith  tne  design  being  centered 
cn  these  issues,  the  potential  to  create  useful  iirranes 
can  be  enhanced.  This  issue  will  be  discussed  ir.  mere 
detail  ir  tie  following  sections. 

Anctler  goal  is  tc  emphasize  portability.  Portability 
should  stress  the  ninimizaticn  of  change  as  a  software 
product  is  moved  frea  one  environment  to  anotner.  Thus, 
portability  in  the  Program  library  will  require  moving  from 
cne  eevnenaent  to  another,  causing  concerns  over  compati¬ 
bility  and  parameter  passing  issues.  These  a..e  seme  cf  the 
issues  that  should  be  dealt  with  by  the  designer  cf  the 
product  and  recognized  •  by  the  user.  The  concept  cf  port¬ 
ability  as  a  goal  fer  the  Program  Library  changes  as  tne 
type  cf  environment  varies.  That  is,  the  concerns  involved 


in  moving  between  twc  unrelated  computer  cj)Vi.:ouiSuts  {i.e., 
IB ri  36C/370  and  Cyber  205}  are  separate  iroi  those  encoun¬ 
tered  in  moving  between  environments  located  within  a  larger 
environment  (e.g.,  the  UNIX  and  VMS  operating  systems  within 
the  VAX  ccnputer  system). 

finally  and  most  importantly,  the  issue  of  reusability 
oust  be  addressee  and  the  concept  incorporated  ante  cue 
library  (from  the  design  staae  to  tne  users  application). 
The  reusability  issue  snoula  be  a  basis  rcr  the  design, 
implementation  and  use  of  the  Program  Library.  Tne  concept 
behind  reusability  should  net  be  limited  to  the  design 
phase,  since  the  extension  of  the  concept  down  to  tne  rest 
primitive  entities  in  the  library  wnx  axso  e n h  a  r.  c  e  tn>= 
user's  programming  task.  Most  users  of  a  software  ..rcuuct 
are  interested  in  increased  savings  (ixi  time  and  money)  and 
increased  productivity  in  programming.  Reusability  is  a 
suggested  path  tc  these  goals,  and  if  tne  Program  Library 
and  its  associated  entities  are  to  reach  the  desired  gcais, 
the  ccrcept  of  reusability  must  be  implemented. 

The  goals  cited  above  for  the  Program  Library  are  by  no 
means  conclusive.  They  merely  provide  a  conceptual  overview 
of  what  a  user  should  expect  from  an  Operational  Program 
library. 

E.  A  HIERARCHICAL  VIEW  OF  TB£  PROGRAM  LIBRARY 

The  Program  library  can  be  described  in  a  Hierarchical 
fasnicc.  The  hierarchy  of  the  Program  Library  consists  of 
entities  embedded  in  multiple  conceptual  layers,  each  layer 
representing  a  library.  An  example  of  a  nierarcaicaily 
layered  model  of  the  Program  Library  is  represented  in 
figure  4.1.  The  layers  cf  the  library  represent  tnree 


conceptual  levels  which  make-up  the  Program  L*r rii:  .  In 
tnis  three  level  exaj.le,  etc  levels  are  classified  as  a  Lew 
level  Library  (ILL),  a  Mid  level  Library  (rill)  and  a  hag., 
level  library  (KIL)  .  Zach  level  can  then  re  described  by 
how  its  associated  routines  are  manipulated  (i.e.,  reused, 
modi f ie a ,  e tc. )  . 

1 .  1 he  Lo w  level  Libra  rv 

A  routine  or  any  entity  at  tne  *jv-.-at  level  is 
writter  in  source  ccce.  It  is  a  stain-alone  entity  - _  a 
routine  which  calls  nc  otner  routine.  Cdi.i  made  no 
routines  at  this  level  are  net  exclusive  tc  any  ore  rcutir... 
cr  package  at  a  nigner  level.  In  ract,  «aen  routine  at  tae 
higner  level  has  access  to  each  and  every  routine  at  a  ic«or 
level.  This  does  net  preclude  tne  anility  to  modiry  ness 
routines  cr  manipulate  them  as  reusable  soitur..  out  tuera 
is  a  implicit  limitation  on  the  sue  (i.e.,  nicer  c;  lines 
cr  cede)  cr  the  roctines  at  tnis  levem.  At  this  level  a 
routine  should  he  expected  to  handle  only  one  accicr.,  crus 
giving  validity  to  the  term  "single  action  routine." 

2  .  lie  Mid  level  Lima r  t 

£ach  entity  at  this  ievei  is  constructed  of  scarce 
language  cede  derived  from  the  linKin^  (via  subroutine 
calls)  tc  lower  level  routines.  Thus,  tne  lower  levels  can 
be  viewed  as  providing  operations  not  availarle  in  existing 
(i.e.,  did  level)  cede.  At  tnis  ievei  tne  size  or  the  enti¬ 
ties  is  of  major  importance  to  tne  capability  of  the 
library.  This  is  evident  in  the  fact  that,  even  though  the 
size  cf  entities  at  this  level  is  comparable  (not  neces¬ 
sarily  larger)  to  tie  size  of  entities  at  the'  lower  level, 
they  are  acre  capable  because  of  the  availability  cf  calls 
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Eierarchy  of  the  Proyran  library 


to  lower  levels.  Uricrtunately,  at  t.as  and  higher  levels, 
as  the  capability  of  the  library  improves,  tne  flexibility 
suffers.  This  is  the  fundamental  tradeoff  between  levels  ox 
a  Program  library;  tie  increased  rower  ci  higher  level  enti¬ 
ties  is  available  oily  by  decreasing  flexibility. 

5 .  The  Hi  gh  Level  Liar  ax  , 

The  average  user,  not  wanting  to  waste  time  writing 
a  program  from  scratch,  seexs  code  representative  ox 
complete  components  (i.e.  ,  application  packages).  lo 
satisf}  this  reguest  tne  Program  Liarary  has  a  Hi-*.  Uvc. 
library  accessible  by  the  user.  As  witn  tne  lower  level 
libraries,  its  contexts  are  still  essentially  modifiaxle  an: 
reusable.  The  size  of  tne  application  gacnaaes  axe  :cfe- 
fully  small  (relative  to  packages  constructed  from  unlayered 
libraries)  ,  but  have  signixicant  capaxiiity.  This  a^air. 
poses  the  issue  cf  a  tradeoff  between  capaxxi^t/  and  flexi¬ 
bility  with  the  user  being  the  bene ficiary  of  the  final 
res  alt. 

C.  ADVANTAGES  Of  A  HIERARCHICAL  PROGRAM  LIBRARY 

In  the  structure  shoun  in  figure  4.2,  if  a  entity  at  tne 
highest  level  (level  2)  wants  to  make  use  of  a  entity  at  the 
lowest  ievel  (level  1),  the  calling  sequence  must  make  use 
cf  the  entities  at  the  mid  level  (leve*  2) .  And  sxculc  the 
routine  labeled  B  wish  to  use  the  routine  labeled  G,  it  must 
pass  through  the  routines  labeled  A  and  C,  since  they  are  in 
the  hierarchical  calling  sequence.  Tnis  type  design  is 
similar  tc  the  designs  that  use  the  concept  of  stet«ise 
refinement.  Therefore  the  flexibility  available  to  the  user 
is  limited. 


40 


figure  4.2  A  Hierarchical  Structure. 


The  Ercgram  library's  structure  as  shown  in  Figure  4.3, 
erf  ere  rest  of  the  relations  sought  in  Figure  4.2,  cut  the 
cnigue  distinguishing  feature  is  tne  potential  to  deviate 
from  the  ncimal  calling  sequence.  That  is,  the  principles 

i 

|  associated  with  stepwise  refinement  in  a  hierarcaical  struc- 

ture  are  still  relevant  with  this  design.  Though  new,  the 
user  has  the  ability  tc  perform  manipulations  (i.e.,  calls 
to  routines)  from  high  levels  to  low  levels  witaout  passing 

I  through  the  middle  levels.  For  an  example,  routine  A  at 

level  3  can  make  use  cf  routines  C,  2,  F,  or  G  a.t  level  1. 
Another  example,  illustrated  in  the  figure,  provides  the 
ability  for  two  cr  mere  routines  at  the  same  level  (e.g.,  3 

and  C  cf  level  2)  to  make  use  of  any  routine  at  level  1 
(e.g.,  L,  £ ,  F  and  G).  A  mere  indepth  explanation  cf  this 
and  the  previous  mentioned  relation  can  be  found  m  the 
article  ly  Earnas  £Hef.  9]  cn  the  "uses''  relation. 


Even  though  the  programs  in  the  'multiple  xevei'  Program 
library  may  be  identical  tc  those  in  a  single  level  design 
•(similar  tc  that  of  the  IHSI  Library)  ,  giving  the  user  guick 


Figure  <1.3  Hierarchical  Structure  or  a  Program  library. 


access  tc  the  programs  at  the  lower  levels  will  ailcw  him  or 
her  tc  use  the  library  more  effectively.  With  the  hierarch¬ 
ical  design,  the  user  now  has  a  iarge  selection  of  rcutir.es 
for  writing  programs  cr  high  level  applications.  If  there 
is  a  need  tc  modify  a  high  level  program,  the  user  crly  need 
to  optimize  the  calling  seguence,  since  tne  programs  are 
writter  in  terms  of  calls  to  lower  level  pregrams.  Since 
tne  programmer  can  aedify  the  program,  he  or  she  has  the 
ability  to  add  or  delete  the  capability.  Also  with  the  tse 
ci  calls  tc  lower  level  programs  the  size  of  the  higher 
level  pregrams  are  net  nearly  as  large  as  tnose  used  in 
different  designs.  Finally,  the  hierarcnical  design  is 
consistent  with  the  state- cf-the-art  technology,  knewn  as 
"modularity 


1 .  iowe£  and  Flexihili ty  in  a  Program  Library 

Eoth  power  ard  flexibility  of  a  Software  Frcauct 
begin  ir  the  design  phase  of  its  life-cycle  and  both  affect 
the  user's  programming  efficiency.  The  granularity  (i.e.. 


size)  c£  the  Program  library  should  represent  a  major  ingre¬ 
dient  in  the  library's  nil  for  power  and  flexiniiity .  In  an 
attempt  to  provide  both  conceptual  goals,  while  keetins  tne 
granularity  of  the  library’s  entities  as  small  as  possible, 
any  and  all  tradeoffs  should  be  examined.  One  anticipated 
example  cf  a  tradeoff  is  due  to  the  issues  around  entity 
size.  That  is,  in  order  to  maintain  the  size  of  entities,  a 
hierarchical  approach  to  program  creation  and  mcdir rcatioa 
should  be  used.  As  the  entities  are  raised  to  a  hijcer 
level  in  the  hierarchy,  the  more  capable  the  library  will 
become,  while  the  degree  cf  rlexiirl it/  is  lessened. 
Although,  the  two  concepts  are  eguaily  important  to  the 
design  and  eventual  implementation  of  the  library,  there 
will  be  instances  where  one  will  be  prefered  to  the  ctner. 
The  designer  and  user  cf  the  Program  Library  should,  at  all 
times,  seek  an  ecuitable  balance  between  pcvsr  and 
flexibility . 


Iren  the  prospective  of  the  users  ox  the  Program 
library,  programmers  or  any  level  of  proficiency  will  be 
able  tc  write  applications  easily.  The  novice  she uin  oc 
able  tc  implement  entire  applications  with  a  minimum  number 
cf  calls  tc  lower  level  routines.  A  more  experienced 
programmer  should  be  able  to  generate  a  greater  repertoire 
cf  routines  for  establishing  applications. 


V.  3 HE  A ED I T 1C N  OF  AN  AFELICATION  GiNZfiATCE 

lie  program  Library  has  rteu  described  as  a  Soi tw are 
Eroduct  designed  as  a  hierarchical  structure  or  libraries. 
The  concept  provides  tne  designer  and  tne  U3  01  d  h  i'y  l 
effective  and  reusable  software  tool.  Even  tfccjji.  tlv. 
rrogxau  library  suggests  to  the  user  a  new  and  "easy"  aetnoi 
for  tie  improvement  tc  program  productivity,  it  still 
requires  that  the  user  have  seme  formal  grograamir. 
edge.  Thus,  it  is  net  as  '•  user-f rienuxy "  as  txrect  =  c  ic-i 
product  based  on  a  high  level  language.  A  r.ign  It  vel 
programming  language  that  cculd  he  ustd  to  easily  u:.u 
succinctly  express  problems  wcula  be  a  very  valuable  tcol 
for  improving  programmer  productivity .  One  approach  tc  this 
has  beer  tc  investigate  "Automatic  Programming"  systems, 
iaizer  [Eef.  16],  gives  an  example  of  a  system,  that  wcuid, 
for  ary  pretlea,  au tcaatic ally  construct  a  working  pregram 
from  a  description  ir  a  very  high  level  language.  Iris  wer* 
has  net  yet  produced  a  practical  system  that  is  easy  for 
non- p togiammer s  to  use;  the  difficulties  in  resolving  ambi¬ 
guities  acd  inconsistencies  in  the  problem  statement  seem 
intractable,  in  at  least  the  near  future.  A  seccnd 
approach,  that  is  practical,  is  to  work  witnm  a  limited 
problem  domain  where  the  problem  is  well  defined  and  there 
is  at  available  notation  tc  resolve  any  ambiguities  cr 
inconsistences.  These  systems  are  call  program  generators. 
As  an  example,  the  program  syntnesizer  used  by  many  indus¬ 
trial  corporations  gives  the  capanility  to  generate  any  cf  a 
whole  class  of  similar  programs  and  the  user  needs  cnly  to 
input  special  information  related  to  his  particular  applica¬ 
tion.  Cn  the  basis  of  this  input,  the  system  outputs 
reasonably  standard  code  adapted  appropriately  fer  the 
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user's  tasx.  Examples  of  this  product  include  fic^iaoi 
generators  for  industrial  ap p lications  such  as  scheduling, 
inventory  management,  cr  payroll. 

To  put  the  user  in  a  position  where  he  or  she  reed  rot 
te  experienced  programmers ,  the  designer  of  a  higr  level 
language  should  further  simplify  the  so  calxea  "hign  level 
language"  (e.g.,  FCSTLAN)  .  One  method  of  simplifying,  a 
FCRTFiN  like  language  is  by  the  collapsing  of  several  lir.es 
cf  common  patterns,  such  as  tne  LO-locp  or  FCF.-loo*,  into 
just  cue  or  two  symbols.  The  language  A?L  ny  lversicn 
(1972)  [Eef.  17],  gives  an  example  of  how  tris  can  he  done. 
Virile  the  level  of  the  API  language  may  not  express  th-s 
level  to  which  the  program  generator  is  proposed,  it  aces 
give  a  conceptual  view  of  what  is  expected  of  the  3er.eratcr. 

In  accordance  with  tne  hierarchical  model  proposed  nor 
the  frogram  Library,  the  program  generator  should  also  be 
represented  as  a  level  ox  the  nierarcny.  Tne  level  should 
be  referred  to  as  the  application  generator  as  shewn  in 
Figure  5.1.  As  with  the  Program  Library,  it  snould  include 
varices  program  generators  consistent  with  tne  organizations 
overall  coals  (i.e.,  business,  statistical  analysis,  etc.) 
The  program  generators  should  respond  to  the  Application 
Generator's  environment  in  a  similar  fashion  to  the  way  the 
libraries  respond  within  the  Erogram  Library's  environment. 
Therefore  the  program  generator  can  be  modified,  and  reused 
in  a  manner  similar  to  that  cf  a  routine.  As  the  figure 
implies  the  Inventory  Management  element  cf  the  application 
generator,  being  a  program  generator  itself,  must  be  viewed 
as  being  on  the  same  level  as  all  the  ether  generators. 
Thus,  each  must  be  capable  cf  communicating  down  tc  the 
various  levels  of  the  Program  Library.  An  important 
restriction  on  the  picgram  generator  is  that  its  components 
are  net  permitted  tc  communicate  directly  with  each  ctner. 


figure  5.1 


Hierarchical  Structure  with  Additional 
application  generator. 

Kitn  the  very  high  level  application  generator  the  Hierarch¬ 
ical  structure,  previously  presented,  remains  valid  ar.a  now 
the  user  has  a  acre  cser-f r iendly  system. 

A  clcser  look  at  the  application  generator  will  .illus¬ 
trate  one  method  of  writing  similar  programs.  The  metnci  is 
to  segment  the  reguired  task  into  two  parts,  routine 
portions  that  are  ccamcn  tc  all  programs  at  that  level  and 
task-dependent  portions  that  must  be  different  for  each  new 
program.  Ihe  program  generator  will  respond  as  a  program, 
that  automatically  executes  the  more  routine  portions  cf  the 
program  task  and  enables  the  user  conveniently  to  input  the 


task-deg endent  iifcraation  sc  that  t/;e  desired  program  can 
be  created.  Mora  detailed  discussions  cn  hew  this  is  accom¬ 
plished  can  be  found  in  £fief.  18]. 

The  simplicity  of  this  software  product  becomes  evident 
when  the  generator  acts  as  an  automatic  program  generator 
for  applications  specific  to  a  wording  environment.  Ihe 
Program  Generator's  efforts  are  aimed  at  ^rvirg  the  user 
with  no  traditional  programming  expertise  the  anility  to 
generate  useful  programs  while  working  with  familiar  terms. 
Ike  Easiness  Definition  language  (311)  system  being  devel¬ 
oped  at  IBM  (Goldberg,  1 S 7 5 } ;  Hammer  et  ai,  lS7h  and 
P50 IC  £ YS1 EM  I  (Martin  et  al  - ,  1974)  at  MU  are  examples  ci 
an  automatic  program  generator  xor  tne  user's  environment 
£Ref.  19],  [fief.  20]  and  [fief.  21]  respectively. 


To  provide  a  working  example  of  tne  program  aej.er5tci, 
as  it  irteracts  with  the  user  and  the  Program  Iirraij, 
figure  5.2  is  provided.  Ihe  figure  illustrates  tne  flow 
chart  created  hy  the  user  within  an  interactive  grapnics 
program  package.  It  also  illustrates  the  interface  between 
the  generator  and  the  Program  Library.  Ihis  interface  is 
transparent  to  the  inexperienced  user  out  tne  experienced 
user  is  allowed  access  whenever  he  or  she  desires.  Ihe 
diagrams  as  shewn  describe  the  program  as  it  is  being 
created;  they  could  also  be  thougnt  of  as  the  program  cr  at 
least  part  of  it.  £ince  this  generator  can  re  described  in 
terms  or  another  such  flow  chart,  then  from  a  cc£cettuai 
standpoint,  more  that  one  generator  may  be  permitted  in  the 
application  generator  at  the  higher  level.  Ihe  generator  at 
tnis  pcirt  is  still  consistent  with  the  Hierarchical  struc¬ 
ture  representing  the  Program  library  and  the  environment 
surrounding  it.  The  specific  design  of  the  program  gener¬ 
ator  is  to  make  the  user's  task  as  simple  as  possible.  With 
this  ir  mind,  the  following  process,  in  Figure  5.2,  is 
outlined. 
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figure  5.2  Example  of  a  Program  Generator. 


Given  a  programmer  concerned  witn  processing  orders,  he 
must  first  make  his  objective  clear  to  the  interactive 
program  package,  presumably  being  used  as  the  peripheral 
device.  Incidental  to  the  processing  or  orders,  a  checK  of 
the  program  file  is  made.  This  is  to  verity  the  existence 
cf  the  required  program,  tut  not  halt  the  rrocess  ir  tne 
program  is  rot  present.  Once  the  objective  has  reen  identi¬ 
fied,  tie  specific  process  of  interest  to  the  user  is 
invoked  by  the  Program  Specification  Language  (PSL)  .  Ihe 
mechanics  of  the  above  operation  is  automatic  in  nature  and 
transparent  to  the  iser.  But,  should  tne  user  require  a 
more  optimal  solution,  he  or  she  has  the  capability  ox 
manipulating  appropriate  application  packages  or  routines 
within  the  Program  library.  The  interface  between  the 
Program  Gereratcr  aid  the  Program  Library  must  be  well 


defined  ana  capable  of  extending  the  user’s  manipulative 
control  down  to  tie  lowest  level  or  the  hierarchical 
structure. 

Ihe  significance  of  tnis  product  is  to  introduce  the 
roticn  of  simplicity  and  of  reusability.  Sy  implementing 
user-friendly  (high-level)  lanyuages  with  special  (task 
crierted)  operators  and  forms  designed  ror  rarticular  tVp.es 
cf  confutation ,  repetitious  ccdin3  of  programs  may  le  eiimi- 
nated.  These  higher  level  langua3es  are  meant  tc  include 
constructs  that  are  adapted  rcr  particular  applications  and 
t.iat  are  natural  fcr  conceptualizations  in  tne  prcrj.en 
domain.  Hopefully,  such  languages  will  allow  the  programs 
to  re  concise  and  efficient.  Since  tne  generator  Operated 
somewhat  automatically,  the  user’s  anility  tc  produce 
correct  and  reliable  pircgraas  snould  be  consideraily 
improved.  This  insures  increased  program  troductivity. 

Examples  of  Program  Generators  and  Program  Libraries  are 
in  existence  and  marketable  today,  hut  as  far  as  it  can  he 
determined,  there  is  not  a  software  product  on  the  market 
that  provides  a  combined  environment,  as  exhibited  above. 
This  is  net  to  imply  that  similar  products  do  not  exist.  As 
an  example  of  one  erganiz atien’s  efforts  at  bringing  the 
concepts  cf  the  generator  and  the  library  together,  the 
following  is  worth  mertioning. 

The  Irternatioral  Mathematical  and  Statistical 
libraries,  Inc.  (IMSl)  known  for  its  numerical  coapu taticral 
library,  designed  a  system  for  a  user  so  that: 


his  programming  effort  could  be  reduced; 
he  could  have  improved  error  control; 
he  could  have  a  system  which  is  designed  for  ease  of 
use,  wifh  the  intent  of  increasing  problem-solving 
productivity ;  and 

he  would  net  be  restricted  to  a  single  computer 
environment. 


I  MS  i 1  £  solution  to  assiotiJij  the  user  is  called  "PECIiAN," 
(for  PECgraa  IRANslatcr)  i&et.  22 J.  PEG  If,  AN  is  designed  as 
a  family  of  software  products,  built  arcund  a  pr eprccessor 
that  produces  FORTRAN  code  which  rerforms  the  actions  speci¬ 
fied  by  the  user’s  FrCTEAN  statements.  The  FORTRAN,  thus 
produced  by  the  preprocessor  is  combined  with  any  FCflEAN 
the  user  may  have  written,  and  then  it  is  compiled,  licked, 
and  executed.  In  cider  to  reuse  the  PRC1RAN  programs  on 
different  problems,  it  is  necessary  to  write  tne  prc3rai  m 
such  a  way  that  new  data  can  be  input  and  to  insure  teat  the 
command  file  (JCL,  macro,  etc.)  does  not  delete  the  execu- 
taixe  program  fixe.  The  coordination  re  tween  PROTEAN  ar.u 
the  IKS!  library  offers  ma  r.y  advantages  to  the  user,  scot 
which  are  highly  scugr.t  in  tne  Program  Library  and  applica¬ 
tion  generator. 

1 .  Advantages  of  £ E CT R A N 

Tne  advantages  of  PROTEAN  are  extensive,  sc  the 
following  suggest  onlj  a  few  cf  the  more  dominate  issues; 

-  Formal  programming  knowledge  is  not  required  fer  ap¬ 
plications  that  can  be  dene  using  FRCTRAN  statements 
alcne. 

-  FORTRAN  can  be  easily  intermixed  with  FROTRAN  state¬ 
ments,  allowing  a  tailored  approacn  to  problem  solv¬ 
ing,  for  the  berefit  cf  the  experienced  user. 

-  Based  on  proven  algorithms  from  the  1MSL  Library,  it 
provides  users  with  tested,  reliable  methods  fer  prob¬ 
lem  solving. 

-  PROTEAN  is  powerful,  flexible  and  ease  to  use.  It  has 
•  accurate  and  informative  error  messages  and  it  allows 

unrestricted  access  to  FORTRAN  for  speciali2ed  iccai 
.  reguiremen ts. 

-  It  allows  user  to  specify  a  programming  problem  in 
altercate  ways. 


-  User  documenticr  in  machine  r=dQdi.ie  form  is  lade 
available  to  tie  systen  implements  rs.  This  allows 
them  to  generate  a  'Help*  facility  for  their  users. 


2.  Sumaarv 

The  intent  cf  this  section  is  to  emphasize  that 
there  is  a  marketable  need  fer  software  products,  such  as 
the  application  penerator.  £ore  importantly,  whet  ccatn.ec 
with  a  Jrcpram  Library,  it  provides  a  more  functional 
product  for  the  user  and  his  workinu  environment .  The  l.w.SL 
library  should  te  viewed  as  a  product  union  provides  seme 
lessens  to  te  learned. 


VI 


•  INDEXING  AND  BITBIEVAL  FECa  THE  PRCGRAa  LIEEAEY 

Ihe  Program  Library  offers  muon  to  the  user  of  a  soft¬ 
ware  product.  ,  But  the  significance  of  tne  liirarj  is 
negated,  if  the  use,r  can  not  access  and  retrieve  entities 
such  faster  than  the  time  required  to  write  an  eauiva*ent 
program.  This  search  and  retrieval  process  aust  c;ecu  a 
work ire  environment  conducive  to  noth  eriiciency  and  .  rc:  ac¬ 
tivity.  The  library  should  re  designed  so  a^  to  i:.ac: . 
entities  (i.e.,  routine  and  .icjraasj  and  ether  program.:  i;.: 
tools  which  will  alleviate  the  need  for  a  user  to  cor.  ti;.o- 
aily  rewrite  programs  for  each  new  application.  The  true 
ef f ectiveness  is  exhibited  by  tae  user's  familiarity  wit;, 
the  entities  that  are  available  and  now  trey  are  called. 
Thus,  the  ^oal  is  tc  provide  a  Program  Library  which  server 
its  purtcse  best  by  giving  the  user  a  fast  way  tc  lccate 
entities.  The  concepts  mentioned  are  not  new,  trey  nav= 
beer,  studied  extensively  ry  Belinda  Thedens  £  Eef .  23j,  with 
results  that  could  make  the  Program  Library  nighiy  effec¬ 
tive.  Tbedens'  results  provide  a  conceptual  view  consistent 
with  the  idea  of  a  Program  library. 

The  Program  library  has  been  uesigned  to  support  a  hier¬ 
archical  structure  consisting  of  multiple  levels  of 
libraries,  each  accessible  by  the  user.  The  entities  within 
tne  library  are  well  documented  m  a  descriptive  manner. 
Thus,  the  documentation  can  re  used  to  assist  the  user  with 
issues  cf  form,  parameter  passing  teenuigues,  error  handling 
procedures  and  any  otter  standard  features  pertinent  tc  the 
library  and  its  manipulation.  These  and  other  features  must 
he  maintained  to  make  the  library  effective,  out  the  effi¬ 
ciency  cf  the  Program  Library  is  more  dependent  on  the  speed 


kith  which  the  iibraiy  entities  can  be  searches  oat  ry  the 
user.  Thedens  suggests  that  a  software  product  in  associa¬ 
tion  with  the  Prograa  library  be  used  to  neip  the  users 
access  and  retrieve  the  needed  routines  and  to  exglair.  new 
they  should  be  used. 

2.  IIEGiBX  REF SEENC  I  GUIDE 

£Eef.  23]  introduces  the  concept  of  a  library  fere rerc= 
Guide.  Ike  Reference  Guide  could  be  an  on-line  gusry 
program,  a  traditiocai  manual  that  eacn  grcaramE.er  car.  f. se¬ 
en  his  (her)  desk,  or  a  ccrrination  or  noth.  for  tie 

purpose  or  this  thesis,  the  on-line  -aery  pro.,rai  will 
the  type  reference  guide  described.  lie  Reference  Guido 
should  be  viewed  as  a  software  product  which  provides  an 
interface  between  the  user  and  the  Program  library. 

The  Reference  Guide,  like  the  Program  Library,  has  take., 
some  ideas  from  the  organization  cf  the  traditional  library. 
Cne  feature  in  particular  is  in  tae  organization  and 
indexing  which  functions  like  a  card  catalog.  Ihe  index 
snould  consist  of  Keywords  that  are  used  when  calling  at  a 
selection  of  on-line  files.  This  snould  be  easily  relate! 
to  a  user  who  is  fairiliar  with  such  traditional  indexing 
tools  as  the  KtflC  (key-wor d-in-context)  whicn  accompanies 
tne  IkSl  library.  The  indexing  of  files  makes  the  user’s 
task  cf  locating  entities  much  easier  than  writing  them,  but 
for  the  user  to  make  use  or  the  Reference  Guide,  it  must 
also  be  simple  to  use.  Tc  maintain  a  hiah  degree  of 
simplicity,  the  description  of  what  the  entities  are 
designed  for  should  be  organized;  the  organization  should  be 
such  that  the  descriptions  are  kept  to  a  few  lines  or  ste^-s. 
Ey  maintaining  short  descriptions,  tne  user  is  ret  begged 
down  with  massive  aacunts  cf  information  which  lessens  the 
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decree  of  understanding  wnile  increasing  the  user's  ieeiing 
cf  complexity.  The  short  descriptions  can  he  treated  as 
weii  defined  nodules  which  can  he  modified  to  describe  the 
entities  that  have  also  been  modified. 

Kith  the  documentation  playing  suca  a  major  role  ir.  the 
effectiveness  of  the  Program  Library,  some  cf  the  concerns 
observed  in  £Eef.  24"  should  he  reiterated.  One  concern  is 
that  the  functional  descriptions  of  how  an  entity  per  ferns 
its  function  internally  should  c<=  miden,  so  as  to  ailow 
flexibility  in  writing  future  versions  of  the  entities.  The 
documentation  should  also  contain  a  description  or  the 
inputs  and  cut-uts,  particularly  tne  formats  and  ranges  or 
values.  Finally,  the  documentation  should  include  descrip¬ 
tions  of  the  side  effects  of  usina  the  entities  (e.g.,  wmen 
registers  get  destroyed,  wnioh  work  fields  are  used  and 
which  status  flags  are  affected) .  Tne  user  should  he  ailc 
to  use  these  items  cf  information  tc  avoid  having  to  examine 
the  code  that  performs  the  function. 

Ite  library  Reference  Guide  should  be  task  oriented  and 
the  techniques  cf  stepwise  refinement  should  be  used  to 
describe  the  entities  (from  the  most  general  to  the  mcr<= 
detailed  levels).  The  importance  placed  cn  testing  the 
entities  of  a  Program  Library  should  be  extended  tc  the 
documentation  , used  tc  describe  the  library  guide.  The  accu¬ 
racy  cf  the  library  documentation  could  be  a  deciding  point 
as  tc  whether  the  Hilary's  resources  are  used.  Tne  actual 
testing  should  involve  checking  for  omitted  inf cr ma ticn, 
information  present  in  the  wrong  order,  typographical 
errors,  and  ambiguous  descriptions.  Each  time  there  is  an 
update,  or  new  addition  to  the  guide,  the  above  mentioned 
tests  should  be  accomplishe d.  The  dates  of  these  modifica¬ 
tions  should  also  be  kept  on  file,  so  asto  assist  the  user 
in  identifying  the  changes  as  related  to  his  particular 


task.  Iherefore,  tie  user  will  not  be  required  tc  reac  tne 
entire  library,  just  that  in  his  or  her  area  cf  concern. 

1  •  Cn-ljne  £uer j  Prour am 

Cne  approach  to  Theders'  on-line  Auery  program  is  to 
have  it  perform  search  and  retrieve  processes  on  the  Program 
library  with  the  use  of  keywords.  An  example  shewn  in 
Figure  6.1  can  be  described  as  follows:  from  the  perspec¬ 

tive  cf  the  user  who  requires  a  routine,  but  is  unfamiliar 
with  the  specifics  of  the  routine  (i.e.,  what  it  is  designed 
to  ic,  what  are  its  parameters,  wuich  routines  does  it  carl, 
etc.),  a  keyword  or  list  of  keywords  can  be  extracted. 

User's  Query 

Ihe  user  can  then  establisn  a  ^uer^  from  the  identi¬ 
fied  (user's  best  selection)  keywords.  Ihe  user's  ^uery  car. 
he  organired  using  different  Bethels.  One  method  consistent 
with  [fief.  23],  suggests  that  every  routine  in  tnc-  Program 
library  he  described  in  snort  sentences  containing  a 
subject,  a  verb,  and  possibly  a  modifier.  Tue  words  ir  the 
senterce  which  are  net  keywords  (e.g.,  and,  or,  for,  a,  the, 
etc.)  will  he  deselected  by  the  translator.  Another  iiethod 
is  tc  provide  keywords  with  boolean  connectives;  for 
example,  given  three  keywords  (A,  3,  C) ,  they  can  be 
processed  by  the  translator  as  A  or  (3  and  C) .  A  scan  of 
the  library  file  would  identify  either  keyword  A  or  else 
both  keywords  B  and  C.  A  more  likely  strategy  uses  inverted 
indexes  which,  fer  each  of  the  three  keywords,  contain  lists 
cf  the  document  references  exhibiting  the  particular 
keyword.  Ihe  search  process  for  the  guery  tnen  perforas  an 
intersection  of  the  document  reference  lists  corresponding 
to  index  terms  3  and  C  to  identify  items  appearing  on  betn 
lists.  Ihe  resulting  list  is  then  merged  with  the  document 
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figure  6.1  Hatching  or  User's  Queries 
Against  Erogram  Library  Entities. 


reference  list  corresponding  tc  term  A  to  ottain  all  items 
located  either  cn  the  A  list  cr  on  the  combined  E  and  C 
list.  Independent  cf  the  method  used,  the  translator  will 
he  reguired  to  handle  the  guery.  The  latter  method  repre¬ 
sents  a  guick  search  facility,  thus  it  will  he  usee  to 
further  explain  figure  6.1. 

Query  Translator 

The  guery  translator's  function  is  to  format 
keywords  {i.e. ,  break  the  guery  down  into  its  component 
parts,  (individual  terms  and  boolean  connectives)}  her  input 
to  a  temporary  storage  (e.g.,  a  memory).  The  translator 


must  alsc  maintain  the  yuery  intact,  so  that  it  can  he  used 
latex  as  a  check  against  the  routines  and  tee  keywords 
returned  tc  the  user.  The  keywords  are  maintained  to  allow 
the  resclver  to  perform  its  functions. 

Keyword  Storage 

Ihe  keyword  storage  acts  as  a  memory  for  storing 
distinct  terms  (keywords)  temporarily  in  a  predefined  formal, 
(i.e.,  parallel  with  n  cells  fer  n  terms).  The  keywords 
should  he  held  in  storage  until  the  search  process  has  been 
completed  or  until  deselected  by  the  user.  The  format  of 
the  terms  is  importart  to  the  next  step  of  the  process  which 
uses  the  term  comparator. 

Term  Comparator  and  Document 

Ihe  comparator  matches  the  identifying  information 
from  the  document  library  file  against  the  yuery  terms.  To 
avoid  having  to  page  througn  the  entire  library  file,  the 
comparator  receives  cnly  the  keywords  associated  with  the 
routine's  function.  The  comparator  should  re  built  to 
handle  truncated  terms  (with  missing  prefixes  as  well  as 
missing  suffixes  and  so-calied  "don't  care"  characters). 
Kith  this  facility  the  guestion  of  ambiguity  must  be 
addressed.  Figure  6.2  shows  a  hierarchy  of  keywords,  asso¬ 
ciated  with  similar,  tut  different  routines.  The  ambiguity 
becomes  a  factor  when  the  routines  are  searched  using  the 
truncated  keyword,  thus  calling  the  routine  INIT  cr  INIT* 
could  return  either  cf  the  structures.  To  avoid  ambiguity 
the  comparator  will  return  both  routines,  giving  the 
resolver  cr  eventually  the  user,  the  option  of  selecting  the 
appropriate  routine.  The  terms  returned  to  the  comparator 
are  possible  because,  as  Thedens  suggests,  the  library  guide 
is  constructed  such  that  each  entity  (i.e.,  pregram, 
routine,  etc.)  is  preceded  by  documentation  information 
consistent  with  a  design  template.  The  template  will  be 


Figure  6.2  Hierarchy  or  Keywords. 


designed  with  a  consistent  format  so  as  to  allow  the  guer/ 
program  ox  the  programmer  when  required,  to  select  tne 
information  needed  without  scxciling  tne  entire  routine.  An 
example  cx  possible  template  heading  argnt  include: 


Description 

Keyword 

Format 

Crigiratcr/P  rcjec  t 
Cn  Inputs 
Cn  Return 
On  Error 
Or  Calls 
fiecuirement 
Cp  tiers 
Special  Case 
Examples 
Opcated 
•  Fcuid  In 
See  Also 
Uses 
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Since  the  template  is  standard  there  hill  he  seme 
routines  which  will  ret  use  all  of  the  neaaings,  the  ones 
that  ccn't  apply  shculd  oe  deleted.  With  tne  "uses"  and 
"found  in"  heading  the  search  process  can  take  on  the 
appearance  of  a  hierarchical  structure.  Ihis  approach, 
snown  in  figure  6.3,  can  easily  he  adapted  for  use  with  the 
hierarchical  structure  used  in  the  Program  Lihrarj  (i.e., 
the  top  cf  the  documenta tier  snouii  point  in  the  right 
direction  and  the  search  of  subsequent  lower  layers  should 
provide  mere  and  more  detail}. 


Figure  6.3  Hierarchy  of  Reference  Guide  Documentation 


Query  Resolver 

The  ^uery  resclver  checks  w.*et her  tie  complete  user 
guery  statement  is  fulfilled  ry  tne  matching  dccunent 
library  terms.  Should  a  returned  routine  not  be  consistent 
with  the  user's  guery,  it  is  deselected.  This  means  the 
user  Kill  net  necessarily  see  all  the  routines  selected  by 
the  comparator.  Once  the  checking  stage  has  teen  completed, 
the  results  are  sent  to  the  output  device  (e.g.,  a  terminal 
or  a  fine  printer)  . 

Search  Output 

The  actual  output  will  consist  of  a  list  of  rcutir.es 
by  rare,  witn  a  short  descriptive  abstract  of  tne  routin'^ 
function  and  other  related  keywords.  Since  tne  document 
library  file  only  certains  the  header  template  rather  tran 
the  dccuirer tation  plus  code,  the  user  snouid  re  acle  tc  view 
the  remaining  documentation  cf  the  routine.  This  could  he 
compared  tc  a  "rrowsing"  facility  wiiich  provides  feecnacn 
ior  guery  refinement. 

retrieval 

Cnee  the  user  has  located  tne  desired  routine  name 
and  is  confident  that  it  does  the  required  task,  he  cr  she 
can  tag  the  routine  for  retrieval  at  tne  end  of  tne  browsing 
session  cr  initiate  the  retrieval  at  that  time.  wner.  the 
routine  has  been  tagged  ror  retrieval,  its  location  witr.in 
the  Program  library  is  identified  (i.  e. ,  pointer  directs  the 
system  tc  its  location  in  memory)  .  Tne  user  can  new  b<= 
prompted  as  to  whether  the  routine  is  to  be  retrieved  (i.e., 
piaced  ir.  the  user's  file)  .  At  this  point  the  retrieval 
process  will  permit  autnerized  users  to  continue  the 
browsing  process  down  to  the  actual  source  code  level,  it 
will  also  allow  updating  (i.e.,  additions  and  deletions)  and 
most  any  manipulation  permitted  in  the  program  library.  The 
retrieval  is  similar  to  the  search  process  in  that  it 


defends  heavily  cn  the  names  and  functions  of  the  entities 
in  the  program  library.  A  major  distinction  retweer.  tns  zvo 
processes  is  the  presumption  that  when  tne  user  invokes  the 
retrieval  process  he  or  she  knows  the  identity  or  the  entity 
and  is  fairly  sure  of  its  location  in  the  program  library. 

frier  tc  using  the  retrieval  mechanism  the  user 
should  re  familiar  bitu  the  hierarcaicai  structure  of  cue 
Program  library.  S  simplified  example  of  wnat  the  user 
snould  ervision  in  the  structure  and  wnat  procedure  could  ne 
used  tc  retrieve  a  routine  at  different  levels  will  be 
presetted.  First/  the  user  should  nave  a  general  urder- 
standing  of  the  library's  structure  for  a  speciric  iapitren- 
taticn.  Ihe  following  should  provide  a  general  assessm  :nt 
cf  the  structure.  The  structure  can  be  viewed  as  cortainirg 
entities  which  are  refered  to  as  its  members.  Ihe  members 
cf  the  structure  are  ordered  hierarchically.  Ihe  aair. 
nearers  at  the  higher  levels  of  the  library  are  cabled 
supersets  tc  any  member  at  a  lower  level  and  likewise  an/ 
member  at  the  lewer  level  is  called  a  subset  of  the  mgher 
levels. 

A  structure  should  define  its  organization  and  the 
tames  of  the  members  on  each  level  in  the  structure.  A 
general  fern  of  the  structure  could  include: 

-  the  name  of  the  member  at  the  hignest  level 

-  the  names  and  attributes  cf  its  members  and 

-  a  level  identifier  for  each  name  tc  define  its  level  in 
hierarchical  order. 

Examples  of  this  structural  form  car.  be  seen  in  the  reccrd 
structure  cf  a  PASCAI  program  or  the  structure  declaration 
cf  a  El/2  program.  2c  illustrate  what  the  user  could  expect 
wnen  retrieving  a  rcutine  from  tne  Program  Library  the 
following  scenario  is  proposed. 
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1o  beain  the  scenario,  a  programmer  is  ,aver  the 
facilities  (i.e.,  hardware  and  software)  of  a  potential 
workstation.  He  or  she  is  expected  to  tax.e  taese  facilities 
and  establish  a  workstation  capable  of  assisting  in  accom¬ 
plishing  their  task  cr  job.  Cne  major  asset  included  ir  the 
facilities  is  a  Program  Library.  The  library  contains  the 
routines  tc  build  essential  programs.  These  programs 
consist  ci  the  appropriate  routines  to  make  a  workstation 
resrcnsive  to  the  programme r ' s  requirements. 

The  facilities  provided  to  tne  programmer  arc 
similar  tc  taose  of  a  SUN  workstation  and  tnus  include:  tne 
capabiJity  to  operate  in  a  catch  or  an  interactive  envirca- 
irent,  the  ability  tc  use  various  input  uevices  (e..,.,  the 
joystick,  the  mouse,  the  track  ^aii  and  the  toucn  screen), 
the  ability  to  produce  either  color  or  monochrome  displays 
(with  varying  hues  ar.d  x-y  addressing)  and  tne  facility  to 
xospcrd  to  a  nuirber  cf  different  software  pacxages  (e.^., 
Tails,  Graphics,  Games  and  Inventory  Management)  . 

The  programmer  must  new  establish  the  correct  facil¬ 
ities  tc  allow  the  workstation  the  capable  of  performing  the 
desired  task.  Ihe  necessary  data  can  he  retrieved  iron  the 
Program  library  as  shewn  in  the  nierarcnical  structure  of 
figure  6.4.  In  the  example,  the  programmer  reguires  a 
graphics  package,  which  is  user  interactive,  with  a  color 
display  controllable  witn  a  mouse.  The  routines  which  will 
give  these  and  other  features  are  stored  in  the  Program 
library  until  retrieved  by  the  programmer  for  insertion  into 
a  program. 

figure  6.5  uses  lot  nctatioa  tc  illustrate  how  the 
programmer  can  retrieve  routines  from  the  Program  binary. 
Kith  the  use  cf  a  library  prompt  (Library  >)  the  various 


routines  car  be  located  and  retrieved  as  shewn.  The  dasred 
lines  around  the  routines  imply  tnat  tne  programmer  should 
te  aide  tc  retrieve  a  routine  directly  without  going  tnreugn 
its  immediate  superset.  For  example.  Library  > 
lib. Graphics. Moveto  can  be  used  to  retrieve  the  lew  level 
routine  teweto,  without  using  routines  at  the  Hid  levels. 


Ambiguities  can  arise  when  referencing  tne  rearers 
cr  a  structure  because  the  rare  cr  a  memrer  can  occur  as  the 
rame  tc  more  than  one  superset.  To  resolve  such  ambigui¬ 
ties,  gualifiea  names  to  reference  members  or  the  library 
structure,  can  be  used.  In  a  qualified  name,  the  member 
name  is  preceded  by  a  list  cf  routine  names  in  ag^ rct r^ate 
order  by  levels,  each  followed  by  a  period.  The  oriy 
routine  rases  required  are  those  that  determine  a  tr.i.ua 
reference  tc  the  member  name.  For  example,  in  the  following 
structure 


1  Graphic 
2  Interactive 
3  Color 
3  House 
4  Kcveto 
4  lineto 
4  Erawtext 
2  Eatch 
3  Cclor 
4  Eisplay 
E  Hcveto 
£  lineto 


£  Erawtext 


Figure  6.4  Example  Hierarchy 
of  a  possible  Program  Library. 
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>  Lib. Graphic. Interactive. 
i‘lo  use 
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>  Lib. Graphic. Inter act ive. 
douse. ieveto 


figure  6.5  Example  of  a  Betrieval  Process. 


a  reference  to  Mcvetc,  Lineto  cr  Drawtext,  or  Graphic. Color 
cr  Graphic.  iSovetc  is  ambiguous  along  witc  a  few  other  rela¬ 
tions.  The  qualified  causes  Interactive. Color  or 

Interactive. Moveto,  cr  Batch. doveto  uniquely  identify  the 
library  routines.  The  fully  qualified  names  would  be 

Graphic .Interactive. Color 
Graphic. Batch.  Color 
Graphic. Interactive. douse. fleveto 
Graphic. Batch. Display.  Move  to 

each  should  hel^  to  alleviate  any  ambiguities.  Ic  shorten 
the  user’s  “request  truncated  names  can  be  used,  tut  as 


illustrated  previously  the  ether  forms  or  ambiguity  cast  he 
rescl  ve  d . 

£.  =Ci!Mi£X 

Ihe  anticipated  seal  ox  the  Library  fieference  Guide  is 
to  siiplify  the  search  an  retrieval  from  and  additions  to 
the  Irocraa  Library.  Simplicity  or  both  issues  should 
improve  cn  the  user's  efficiency,  lessen  the  amount  of  trie 
wasted  locAina  for  the  best  entity,  improve  tne  users 
anility  tc  write  programs  and  finally  and  most  important, 
increase  the  user's  product ivitv. 
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VII.  IHJ  A I A  PROGRAMMING  LANGOAGE  AND  THE  PROGRAM  LIBRARY 

Gcguen  £Bef.  25],  discusses  tne  cost  or  sortware  tcols: 
"It  appears  that  each  successive  generation  or  software- 
development  tools  has  teen  significantly  core  expen sive  than 
the  previous  one.  Hcwever,  these  tools  are  still  much  less 
expensive  than  cor r es t ondin g  hardware  tools,  seen  as  fatri- 
caticr  lines."  Ever  with  this  knowied3e  there  is  still 
great  reluctance  to  invest  significant  amounts  of  money  ir.to 
research  and  development  for  software  toois.  In  fact,  sue-: 
it  nas  teen  discovered  that  mest  of  the  cost  of  real  systems 
row  lies  in  software  rather  than  naraware,  tr<=  reluctance  to 
invest  becomes  even  more  evident.  There  are  seme  ncferui 
signs  which  have  shewn  that  tne  Japanese  "software  facto¬ 
ries"  are  actually  capable  or  achieving  rates  or  reusability 
rangir3  from  60S  to  6C*  £Ref.  25].  Alsc,  some  0.  S.  indus¬ 
tries  anc  specifically  the  Eepaxtment  of  Defense  (Dol)  have 
hegur.  tc  invest  in  the  field  of  software  productivity. 
EoD's  efforts  have  teen  extensively  geared  to  the  develop¬ 
ment  cr  the  programaiirg  language  "Ada,"  wnich  is  designed  in 
accordance  with  reguireaents  established  by  the  DoD. 

The  reguirements  call  for  a  langua3e  with  consideraile 
expressive  power  covering  a  wide  application  domain.  As  a 
result,  the  language  includes  facilities  offered  ty  clas¬ 
sical  languages  such  as  Pascal  as  well  as  facilities  often 
found  only  in  specialized  languages.  Thus,  the  lan3uage  is 
a  modem  algorithmic  language  witn  usual  control  structures 
and  with  the  ability  to  define  types  and  subprograms.  It 
also  serves  the  need  cf  modularity,  whereby  data,  types,  and 
subprograms  can  be  "packaged." 
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he  four  program  units  of  Ada  are  subprograms. 
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units,  task  units,  and  generic  units.  Ihe  two  units  cf 
special  interest  for  a  Software  Library  are  the  package  unit 
and  the  generic  unit.  A  package  is  derined  as  a  cculectior. 
cf  logically  related  entities.  A  generic  unit  is  a  temp- 
late,  which  is  parameterized  or  not.  Corresponding  (ncxgen- 
eric)  subprograms  cx  packages  can  be  obtained  from  tneo. 
lie  resulting  program  units  are  instances  of  tne  original 
generic  utit  and  thus,  forms  ox  "instantiation. " 

An  example  cf  hew  Ada  supports  the  Program  Licrary  is  in 
tne  way  the  generic  program  unit  can  be  used.  It  r.as  iter, 
suggested  that  each  entity  in  the  Program  Library  contain  a 
heading  template  to  ie  used  as  a  means  of  searching  end 
retrieving  the  entities  fer  possible  modification  (i.e., 
deletion,  addition  arc  updating).  Kaat  the  generic  rrcgrac 
unit  provides  is  the  ability  to  net  only  search  axe 
retrieve,  but  also  tc  minimize  the  modification.  One  metnod 
in  which  Ada  exhibits  this  is  snown  neiow  [fief.  2],  wnere  a 
subprogram  is  created  that  exchanges  two  elements  ci  an 
integer  type: 

procedure  1NTEGZR_EXCHANGE  (FiFST,  SECOND:  in  out  INIZGEE) is 

1EEECEA6Y  :  INTEGEE; 
begin 

1EMPCEAEY  :=  FISS1; 

F IE  SI  :=  SECCfD; 

SECCKE  :=  lENICEASY; 

end  1NIFGEE_EXCHANGE ; 

Cnee  this  application  is  established  ether  types  of 
elements  may  be  exchanged  without  creating  a  new  subprogram 
for  each  instance.  With  the  algoritnm  oeing  identical  in 
ail  cases,  the  similar  operations  may  be  factored  cut  by 
adding  the  following  generic  unit  tc  the  procedure 

specification: 
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generic 

type  El ££12 NT  is  private; 

procedure  EXCHANGE  (E1EST,  SECOND  :  in  out  ELEMENT) ; 

The  hcdy  new  becomes: 

procedure  EXCHANGE  (EIKST,  SECOND  :  in  out  ELEMENT)  is 

IEKFCRA5Y  :  EL  EH  EH; 
begir 

1EMPCEAFY  :  =  FIfiSI; 

FIES1  :=  SECOND; 

SECOND  :=  T  EMtCEAaY; 
end  EXCEANGE; 

The  significant  portion  or  this  suopro ^ram  specification 
is  the  addition  of  a  prefix,  called  the  "generic  part,"  tout 
defines  ail  of  the  generic  parameters  (if  any)  .  The  areve 
two  algorithms  have  the  same  identical  body  with  the  excep¬ 
tion  cf  the  data  type  which  is  handled  by  tre  generic  -art. 
This  process,  as  shown,  allows  the  programmer  the  ability  to 
make  use  of  the  existing  body  of  a  program  unit,  instead  of 
vritixg  one  from  scratch.  Sc  witn  this  method,  the  mediri- 
caticrs  are  mainly  performed  cn  the  specirication  (i.e.,  the 
generic  part),  hopefully  minimizing  the  degree  of  change 
necessary.  The  Program  Library  would  manipulate  its  -enti¬ 
ties  in  a  similar  manner,  making  it  ah  least  as  reusable  as 
Ada  makes  its  generic  packages. 

Since  generic  urits  are  just  templates,  they  are  not 
executanle,  and  so  they  may  net  be  used  directly.  Eut  they 
create  irstances  of  the  generic  unit.  Thus,  the  instantia¬ 
tion  cf  the  generic  unit  makes  the  subprogram  on  the  paexage 
sufficiently  easy  to  identify  and  combine  with  other  units. 
Therefore,  the  goals  and  concepts  of  tne  Program  Library  are 
supported  by  the  Ada  program  language  and  although  Ada  may 


not  represent  tne  best  language  tor  the  Horary,  it  aces 
support  the  Program  library  concept,  s=e  £fief.  25]. 

filth  £Be£.  25]  and  £  Bef .  2],  tne  aforementioned  exacries 
are  cade  clear  and  tie  Prograir  Library  is  established  as  a 
potentially  feasible  software  product.  Even  core  supportive 
is  the  reference  made  tc  the  organization  of  a  "Ada  Program 
library."  lhe  reference  makes  similar  rrorosals  tc  these  or 
this  thesis  in  the  area  of  library  construction  arc  ra¬ 
tion.  Specifically  it  suggests  a  hierarcni rax  classiriri- 
tion  senexe,  with  different  levels  of  detail  and  rcraalisus, 
and  with  each  entity  access  icle  b_.  Keywords.  7uis  roes  not 
imply  that  tne  proposals  offered  are  ail  inc^usi.*.  o. 
anywhere  near  ready  fee  inpleaentation.  However,  tn- 
ccncepts  are  not  that  remote  and  at  least  one  organization 
(i.e.,  the  DoO)  is  willing  to  risk  tne  time  and  xeneg  tc 
investigate  the  totertial  tc  achieve  these  conceptual  3cais. 
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VIII.  NON  COJJE  PRODUCTS  IN  SOFTWARE  1IERARIZS 


Even  with  the  Software  Library  representing  an  effective 
reusable  software  product,  one  must  ask.  if  that  is  crouch  to 
encourage  effective  software  development.  Tne  Software 
library  has  been  represented  by  products  (e.*.,  the  Program 
library)  designed  tc  enhance  reusability  of  code.  Aitiougn 
tne  management  an.’:  organization  of  code  is  critical  tc  the 
future  development  of  reusable  sortware,  there  are  other 
software  products  that  are  developed  during  ta«  life-cycle 
that  have  the  potential  for  reuse.  These  include  documents, 

t 

reguire neat s,  specifications,  designs  ana  test  plans.  Just 
as  reusability  in  ceding  can  be  used  to  reduce  software 
coding  ccsts,  so  can  reusability  oi  software  products  ir. 
ether  phases  of  the  life-cycle  contribute  to  cost  reduc¬ 
tions.  Each  of  the  concepts  in  the  conceptual  Program 
library  can  be  applied  to  other  software  products  in  the 
life-cycle. 

The  definition  cf  reusability  has  placed  tne  emphasis  on 
the  capital  returns  cf  a  software  product.  If  it  is  more 
cost  effective  to  use  existing  designs,  specifications* 
reguirements  and  test  plans,  then  tney  should  he  reused. 
Even  with  this  being  the  case,  ir  they  are  not  organized  in 
an  accessible  and  retrievable  manner,  they  lese  their 
reusable  nature.  With  reusability  being  so  important,  this 
issue  must  he  addressed  as  an  objective  cf  tne  development 
process  throughout  the  life-cycle.  To  reduce  the  overall 
cost  of  a  software  product,  all  phases  of  its  life-cycle 
should  incorporate  methods  and  standards  which  will  suppert 
reusability.  Once  the  software  product  is  postulated  as 
being  reusable,  the  issue  must  be  fully  addressed  then  and 
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cot  at  a  cite  later  phase  of  the  Aife-cy c^e.  However,  the 
issue  cf  reusability  should  ret  oe  forced  on  the  design, 
specif icaticn  or  any  other  phase  not  compatible  cc  me 
required  arpiication.  £ach  phase  snouid  be  viewed  sepa¬ 
rately  and  a  determination  made  as  to  whether  reusability  is 
economically  feasible.  If  it  is  then  reusability  sheila  be 
incorporated,  but  if  it  is  net  feasible  it  should  net  be 
insiste  d. 

finally,  since  reusable  soitware  .-redacts  crier  an 
ai-preaen  tc  lessening  the  errects  ox  me  "Soitware  Crisis,  ' 
environ ments  encompassing  this  concept  should  be  estab¬ 
lished.  These  environments  should  re  concerned  with  pi.ases 
cf  the  ^ife-cycle  otier  than  code.  That  which  nas  already 
been  learned  frciu  werkmej  with  reusable  code  sheuie  be 
applied,  thes  avoiding  the  "reinventinj  of  tne  wheel. 


II 


II.  CONCLUSION 

The  "software  crisis"  is  real  and  if  the  computer 
industry  is  to  have  any  impact  on  reducing  its  effects, 
software  developers  just  begin  making  concerted  efxorts  to 
create  reusable  scitware  products.  Ibis  thesis  has 
presented  the  Software  Library  and  its  prototype  the  Frcgran 
library  as  possible  reusable  software  products.  Jletnccs  of 
making  the  concept  of  a  Software  Library  better  understood 
hy  the  user  were  discussed.  Inis  was  accos.plisr.ee  by 
comparison  of  the  Software  Library  to  a  traditional  library 
and  hy  relating  it  tc  other  rrogram  lirraries  (particularly 
tne  IESI  anc  the  NAG).  Ihese  comparisons  yielded  character¬ 
istics  which  could  he  associated  to  a  auality  Software, 
library. 

if  the  Program  library  has  a  hierarchical  structure, 
then  the  entities  within  the  library  can  be  easily  accessed 
and  retrieved  by  a  user.  Reusability  is  thus  estaclisnei  ac 
a  viable  solution  to  some  of  the  economic  problems  in  soft¬ 
ware  development. 

Application  generators  with  similar  hierarchical  struc¬ 
ture  tc  the  Program  library  can  be  used  to  assist  the  inex¬ 
perienced  user  perform  his  or  her  task.  Ine  experienced 
user  shculd  be  allowed  tc  modify  entities  in  teth  the 
Program  library  and  the  application  generator. 

An  on-line  guery  program  was  discussed  as  an  interface 
between  the  Program  library  and  the  user.  Tne  guery  program 
is  ere  approach  tc  bringing  reusability  to  the  software 
product. 
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lie  Aca  pro^raarin j  language  was  described  as  bavin*, 
features  that  support  tne  ccrcept  of  a  reusable  Frcgraa 
library.  Future  ccrcepts  in  the  Ada  prograa  library  which 
are  in  line  with  the  issues  in  this  thesis  are  rererenced. 

Finally,  the  Software  library  should  include  products 
from  phases  of  tie  life-cycle  other  than  ceding, 
locunentaticn,  specifications,  re -uireaents ,  designs  ana 

test  plans  should  be  incorporated  into  the  concept  cf 
Software  Library . 
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